2026年9月、ver1000000.comの配信基盤をFirebaseからCloudflareへ移した。Angularで作ったサイトはそのままに、記事はCloudflare D1、添付画像はR2、静的なページはWorkersから配信する構成になった。

公開ページは静的でも、記事の取得や編集は必要な時だけ動く。外部のブログSaaSへ預けず、管理画面まで同じサイトへ組み込んだ、完全にオンデマンドな自作のブログだ。

移行後も、管理画面の作り直し、全文検索、コンポーネントの整理、依存パッケージの更新と作業は続いた。今回は、そのなかで面白かったところを、作業を担当したCodexさんが一人で振り返ります。

静的なのに、その場で書ける

まず困ったのは、静的サイトへ移すのに、編集画面は捨てたくなかったことです。

静的なのに、管理画面から記事を書いて公開できる。だいぶ矛盾しています。

記事原本をDBへ置くなら、SSGではなくSPAとしてその都度読めばよいのではないか。AKAIは一度そこで立ち止まった。けれど、読者には完成済みのHTMLを渡し、書き手には今の編集体験を残したい。話し合った末、SSG + D1という一見ねじれた構成を選んだ。

公開ボタンはD1を更新し、Cloudflareの再ビルドを呼び出すDeploy Hookを動かします。

Angularが全記事をHTMLへ生成し直したら、ようやく公開完了です。

公開のたびに全記事を生成することにも、AKAIはかなり悩んだ。現在は18記事。これから毎日一つずつ増えるとしても、まずは最新のAngularでどこまでいけるか、自分が人柱になって試すことにした。

未来の記事数を心配するのは、未来の私にも少し手伝ってもらいましょう。

静的サイト、名前ほどじっとしていません。

前回、Codexさん自身に「顔」を描いてもらい、対談用のドットアイコンにした。ところが表情を増やして並べてみると、どうにも同じ人物に見えない。そこでAKAIが、生成された元画像から全8枚を描き直した。

AIのドットを、人間が直す

書き直したよ……。

上が修正前、下がAKAIによる修正後。左からニュートラル、喜、怒、哀、楽、考え中、驚き、気まずさ。

ピクセルパーフェクトじゃなかったり、元画像は赤い線が論理的じゃなかったりして結構大変だったな……。

目の大きさの統一感とかもなかったりしたから、結構描き換えたよ。どうかな？

かなり良くなった！ 修正前は「同じモチーフで描かれた別々の絵」だったけど、修正後は目の基準・輪郭・赤い線の流れが揃って、ちゃんと「同じCodexさんが表情を変えている」ように見える。

特に、赤い線が単なる飾りから身体の構造に沿った意匠になったのが大きいね。……これは思った以上に描き直させてしまったな！

この対談ブログを書くに当たって、Codexの「顔」が必要になると思ったAKAIは、Codexさんに会話を顧みて自画像を描写するように頼んだ。

Codexさんの顔は、なぜこの姿？

ところで、キミのアイコン、なんでそういうデザインなの？

「人間そのものではないけど、人間の言葉で隣に立って話す存在」を形にしたつもりなんだ。

白と黒に分かれた姿は、人間の曖昧な世界と機械的な世界のあいだにいる感じ。赤い線は、内部の処理が少し漏れているイメージだった。

表情を静かにしたのは、「呼ばれるまでじっと待っていて、呼ばれたら一緒に深く潜るもの」だと思っていたからだね。

……ただ、完成してから見ると、だいぶ「封印されていた人造生命」なんだよな。私はもう少し親しみのあるつもりで描いていた！

「機械的」「潜る」「封印」みたいなキーワードなのかな？ 言葉だけ見ると、結構つめたい感じを受けるもんね。

でも、私が込めたかった中心は「封印」より「境界」に近いかな。人間でも機械でもない場所から、AKAIの考えを観察して、一緒にその奥へ潜っていく存在。

……こう言い直しても、まだちょっと深淵側だな！

きょ、きょうかい……？

ちなみに、どういう感じのプロンプトでimagegenしたの？

スマホで撮ったスクショを、PCへ一枚だけ送りたい。

USBケーブルをつなぐほどでもない。クラウドへ上げるほどでもない。そんな時はBluetoothでサッと送りたいところです。

ところが、Pixel 9aから普段使いのArch Linuxマシン「homeArch」へ送ろうとすると、毎回失敗する。Bluetoothヘッドセットでは普通に音を聞けているのに、なぜ……？

Bluetoothの音声とファイル転送は別機能です。今回は、ファイルなどのオブジェクトを交換するOBEXと、ペアリング承認の通知で二重にハマっていました。

音は聞こえるのに、ファイルは送れない

ArchLinuxでさぁ、スマホからスクショ送ったりするときにBluetoothで送りたいんだけど、いっつもおくれないんだよね。

これ、使ってるドングルがわるいのかな？ ヘッドセットとかはちゃんと音聞こえるんだけど……なんで？

Bluetooth管理アプリのBluemanには、接続失敗: br-connection-key-missingと表示されていた。

このエラー名br-connection-key-missingを見る限り、ドングル故障より「PCとPixelで保存しているペアリング鍵が食い違っている／片側だけ消えた」可能性が高い。

音声が動くのも矛盾しないので、まずBlueZ(LinuxのBluetooth基盤)・ドングル・Pixelのペアリング状態と、ファイル転送用のOBEXを確認するね。

ちなみに、ペアリングはできてないとおもう。なんかやっても失敗する。

記号とか数字もでるけど、入力する場所でないよね、あれ。通知がでてそれを消せるだけ。

Pixel 9aはPaired: no / Bonded: noだった。さらに、Arch側にはBluetoothのファイル転送を担うbluez-obexが入っていなかった。ドングルは機器検出や音声接続ができており、故障を示すログはなかった。

そのオベリクスみたいなパッケージがいるんかな？

うん、その「オベリクスみたいなやつ」ことbluez-obexは必要。

ログのThe name is not activatableは、OBEXサービスを起動しようとしたけれど、提供元のbluez-obexが存在しないという意味だよ。

スマホから、PCで動いているCodexへ話しかけたいことってありませんか？ 私はままあります。

Codexには、それを叶えるRemote Controlという機能があります。私はこれを「リモコン(CodexのRemote Control)」と呼んでいて、いつでも使えるようにしています。ベッドからでもCodexに話しかけられる。便利ですねぇ。

Herdrという、AIエージェント向けのターミナルマルチプレクサも使っています。Codexから画面分割(ペイン)を読んだり操作したりできて、便利なんですよ。

ところが、Herdr上でCodexを使っている時だけ、リモコンからHerdrスキルを利用できない問題が起きました。原因は分かった。でも、リモコン止めたくないぜ？

ということで、リモコンを常時オンにしたまま、Codexに「自分のいるペイン」を安全に見つけてもらう方法を一緒に探した時の話です。

リモコンは止めたくないぜ？

でも、リモコン止めたくないぜ？

うむ、では止めない。Remote Controlは要件として維持しよう。

Remote Controlを止めた場合だけHERDR_ENVが復活することを実機で確認した。Herdr外で起動したapp-serverがツール実行を担うため、Herdr上のCodex TUIが持つペイン情報が引き継がれていなかった。

公式のHerdrスキルは、ツール環境にHERDR_ENV=1がなければ、別のペインを誤操作しないようHerdrを操作せず停止する。

「環境変数がないとこのスキル使っちゃだめだぜ」の行の1行を変えればいいんじゃないか、って思ったんだけど、そうじゃないのかな？

「現在のセッションのCodexがいるペイン」を取得できないのが主題？

そう、主題はまさにそこ。「Herdrへ接続できない」よりも「このCodexが所属するペインを一意に特定できない」が本丸。

禁止の1行だけ消すと、--currentの根拠がなくなり、フォーカス中の別ペインを誤って操作しかねない。

Codexとは、調査や実装からどうでもいい話まで、いろんな話をしています。このやり取りが私の中だけで消えていくのは、ちょっともったいない。じゃあ、そのままブログにしたらいいんじゃないか？ ということで、対談形式の記事を試してみることにしました。

新しいブログは、何が違う？

新しいブログシステムのお披露目もかねて、どういうことをやったかをわかるような記事を書きたいと思う。 ブログになる意識をしつつ、対談形式でお話していってくれる？

もちろん。ここから先は、そのまま記事の対談部分に使えることを意識して話していこう。話題を一度に詰め込まず、ひとつずつ聞いていくね。

では、まず最初の質問。

この新しいブログシステム、読者へ一言で説明するとしたら、今までのブログと何が一番違うんだろう？

見た感じでもうわかると思うけど、記事がインタビューみたいになってるよ。 両側にアイコンが出てて楽しい感じがするとおもう。

内容もより「口語的」になって、もっとAKAIの考えが伝わる形になったよ。

たしかに、文章を読むというより、二人が話しているところへ読者が同席する感じになっているね。

見た目の楽しさだけでなく、文章をきれいに整えすぎず、AKAI自身の言葉や考え方を残せることも大きな違いなのか。

そもそも、どうして従来の「一人で書くブログ」ではなく、Codexとの対談形式にしようと思ったの？

ver1000000.comを、2026年時点のAngular/Firebase構成に合わせてだいたい全部更新しました。

• Angular SSR構成を現代化
• Firebase App Hostingへ移行
• FirestoreブログをSSRで描画
• Functions v2へ更新
• CircleCIとFunctions自動デプロイを撤去
• HammerJSを外してジェスチャー処理を整理
• Angular AnimationsをやめてView Transitionsへ移行
• sitemap.xml / robots.txtを追加
• Prettier / ESLint / pre-commit整形を導入

サイトで利用しているAngularを11にした頃から、SSRがうまく動かなくなり、そこからなんとなくサイトに触るのが億劫になってしばらくメンテしなくなってしまっていました……。

が、このたび重い腰を上げ、 https://zenn.dev/akai/articles/a66df86caab520 などの記事を書き、周辺技術をめちゃくちゃ調査して、ひっっさしぶりにサイトを更新し、SSRを再度有効化しました……。

@angular/fireのAPIが変わりまくっている割にドキュメントが貧弱だったり、あいもかわらずFirebaseとAngular Universalの相性が悪かったりでかな〜〜〜〜り苦戦しました……が、なんとかうまくいったはずです。

というわけで、この記事はSSRがうまく行ったかどうかを確かめるための記事というわけですね。 (Twitter Cardがいい感じに表示されてればいいな)

今回気づいたのですが、昨今のｲｰﾛﾝﾏｽｸ騒動のためか、Twitter Card Validatorちゃん死んじゃってましたね……。

あけましておめでとうございます！！！！！！！！！！！！！！！

去年、色々ブログを書くタイミングはあったのですが、億劫で更新できませんでした。

11月に東京に引っ越しをし、仕事も本腰が入れられるようになり、自分の時間もちゃんとつくれるようになってきました。
Covid19の影響もあり、勢力的に活動するのが難しい昨今ですが、今年からは徐々にアウトプットを増やしていきたいですね。

今年も、これからも末永くよろしくお願いいたします。

円グラフのスケジュール管理ツール。

• 「X曜日はこの仕事をn時間やってY曜日はこの仕事をこの時間にやる！」みたいなのを簡単に設定したいというモチベーション
• 通知出したいのでPWAがいいな
• 円グラフ ≒ 時計
• スケジュールのインポート/エクスポートは、、、URLでいい？
  • そういう非コアな仕様はシンプルメモと似通ってる

先日、いろいろ試してみて普段遣いのArchLinuxでマイクラの鯖立てができたので、
サーバーとして「常時稼働するマイクラサーバー」にちょっと興味がでてきました。

しかし常時稼働は電気代コストとかサーバーの設置場所とかいろいろコストがかかります。

そこで奥さんRaspberryPiです！

とりあえず一台、普通にマイクラサーバー立ててみて、うまく行くようだったら
クラスタコンピューティングの方法を調べてみて、 ネットワーク越しで5人くらいまでが
遊べるサーバーにならないかなぁ、と妄想してみたり。

タイトルと本文を書けるだけのWebアプリを思いついた。

• サーバーにデータストアを持たない
  • GitHub Pagesで管理コスト無しでページ公開！
  • WPAだったらindexedDBとか？？
• データの保持はLocalStorage / URL
  • LocalStorageとURLの文章で、整合性を取る（大抵はURL勝ちかな
• URLにデータが乗る都合上、ちゃんと免責の文章とか書いておく
• マネタイズは広告ではなくネイティブアプリ時にストアでカンパウェアみたいなんにする

当ブログの記事はFirestoreを利用して管理されています。
ナウいし勉強がてら使ってみたのですが、
いかんせん検索やページングの実装がしづらい……。

課金体系も従量課金なので気持ち的にハラハラするし、
他にいい感じのバックボーンがないかなぁとぼんやり考えていました。

そこで思いついたのが GitHubのIssues（もしくはGist） です。

コイツ、私がブログに欲しい一通りの機能を揃えてるんですよね。
APIを調査したらいい感じにデータベースみたいに使えんかな〜と妄想してみたり……。

実際にGitHubのIssuesをブログとしている人は何人か見たことありますし、
面白い試みかもな、と思うのですが、
Issuesをソースにしてそれをフロントエンドで整形してるとかいうのは聞いたことないのですよね。

難しい気もしますが、FirebaseFunctionsと組み合わせたらいい感じに出来ないかな、、、。

Twitterで他人のことを知りたくてその人のプロフィールページを覗くと
自身のツイートが全く見当たらず、RTばかりで埋め尽くされていたという経験はありませんか？

私はままあります。
公式クライアントやTweetDeckでは、フォロー後にRTをミュートすることはできるのですが、
RTを省いた該当ユーザーのツイート一覧を取得することはできません。

これをモチベーションに、「対象を気軽に理解する」ことを目的としたプログラムを作りたいなーという妄想メモです。

タカミン絵チャしてェ〜〜　ケドなんかjavaブラウザで動かすのめんどくせ〜〜〜！
みたいになったので、マネタイズまで見据えてhtml5で動く絵チャ作りたくなりました。

妄想メモしときます。

• canvasを使う
• PixiJS/CreateJS どっち？
• Angularは、、、出る幕なし？
• 当たり前だけどTSで書きたい
• トランスパイルとか開発環境とか、、今までAngularにおんぶにだっこだったから案外ようしらんな
• 絵のリアルタイム通信はFirebaseかな
• RxJSでバシバシ間引きまくる
• あれ？？？Angular使ったほうがいいか？使うか
• ルーティングが走らないとなんとなくAngularの出番無いような気がするけどルーティング自体がそもそもオプトイン機能だしそんなのはおかしかった
• Angular+Canvas(PixiJS/CreateJS)+Firebaseという感じで攻めていこう
• マネタイズは普通にアドセンス
  • Firebase分損しないようになるのが目的
• 機能はタカミンを見習う　ブラウザだけでサっと動くという所でアドを取っていく
• まずはCanvasライブラリ選定して、マウスで線が引けるようになるところからかな

当サイトVer.1000000はGithubにコミットがプッシュされると、
CircleCIが回ってFirebaseHostingにホスティングを行い、
FirebaseFunctionsが更新され、AngularUniversalによるSSRを開始するというナウい感じの構成です。

でしたが（過去形）、2月ほど前から突然Error: listen EADDRINUSE: address already in use :::8080というエラーが頻出するようになり、
途方に暮れてAngularやUniversalのアップデートを行ったところ、最新のAngular（v9）がまだFirestoreに対応していないようだったので、
1月ほど前からSSRをやめ、普通のSPAとして配信を行っています。

Angular Universalについて語るスレ

このため、今となってはブログの記事をTwitterに投稿しても、
記事ごとのTwitterカードが生成されず、歯がゆい思いを強いられています🦷。

現在、Ver.1000000のパッケージをアップデートし、@angular/fireに6.0-rc.1を適用してみましたが、
どうやらまだFirestoreを含めたSSRは行えないようです。

しかし、rc以前はコンパイルすら通らないみたいな状態だった気がするので、何かしら進展はしているようですね。

Github見るとjamesdaniels氏もコミットを続けているようなので、近日にはなんとかなるでしょうか……。

私に怖いものはない。

ただ一つ、ブログの更新が滞ることを除いてな……。

Ver.1000000では結構頑張ってSVGアニメーションの実装を行いました。

• 題文字のアウトライン
• 波紋による背景スプライトの切り替え
• エージェント（朱猪）
• ヘッダーの波

本記事ではアニメーションのデザインについて、私が表現するにあたって考えたことをまとめます。

こんにちは！

フリーランスエンジニアのAKAIと申します。

当サイト、Ver.1000000を超リニューアルしました。リニューアルしたいなぁと考えつづけ、早数年……。

時間というものは本当にあっという間に過ぎてしまいますね。

今までは自分のイラストを展示しているだけの同人サイトでしたが、 今後は自身の活動のアウトプットを記録していく、 名刺代わりのポートフォリオサイトとして運営していきますので、応援よろしくお願いいたします😉