AIを使ったソフトウェア開発から、エージェントを育てるところまで
久しぶりにまとまった時間ができたので、なんとなくピックルボールの試合の記録アプリを、AIに手伝ってもらいながら作り始めた。
今は、AIエージェントが自分自身を運用するためのインフラを作っていたり、自分とAIの協働の質を測るツールを書いていたり、自分の生活コンテキストをAIに渡して「小さい判断ぐらいなら任せられるか？」を試したりしている。
数ヶ月でずいぶん沢山のことをやった気がするけれど、別にロードマップがあったわけじゃない。毎回、ひとつのプロジェクトを作ると、そこで遭遇した「ひっかかり」が次のプロジェクトのお題になる。それを繰り返していたら、振り返って初めて、自分が辿ってきた弧（アーク）が見えてきた、というのが正直なところだ。
フェーズ1：AIと「一緒に作っていた」頃
最初の数プロジェクトは、純粋に「AIを使ってどれだけ早く作れるか」を試していた期間だった。
RallyHubは10日でフルスタックのモバイルアプリとして仕上げた。React Native、認証、データベース、オフライン対応、QRコードの出力と読み取り、イベントの管理、DUPR（ピックルボール界のレーティングシステム）との連携(現在最終レビュー中)まで、ひとりで全部組んだ。これはまだ開発が継続している。
Moyaiは1月に作った。「欲しい」と「あるよ」をプライバシーを守りながらマッチさせる、というコンセプトの試作品。技術的にはSemantic Matchingという言葉から意味を抽出して、その近似性から「あげます」を「欲しい」に繋げて、その後の商品(無料)のやりとりを手助けして…という仕組み。だいたい1週間で形になったけど、実社会で使ってもらうには相応のコミットメントが必要になると思ったので休止中。
Kokoroは、妻に「ソフト開発がタダだったら何が欲しい？」と聞いて出てきたアイデアからスタートした、ペルソナ駆動のチャットアプリ。WebとLINEの両方で動く。「マツ◯・デラックス的なキャラで」とか、ペルソナをカスタマイズして「話を聞いてもらう」ことに特化してあれこれ実験して、なかなか楽しめた。
3つ作って、書いたエッセイも3本。そのどれもが、結局は同じことに気づいていく過程だった。AIは「実装時間」は劇的に圧縮してくれる。でも「判断時間」は圧縮しない。
何を作るか、誰のために作るか、どこまで作るか、ユーザーがいないときにどう仮説検証するか。実装が早くなった分、こういう設計判断の曖昧さが、相対的にずっと重く感じるようになった。それと、AIが圧縮してくれない部分——ユーザーを見つける、フィードバックループを回す、必要な忍耐——が、「同時に何本のプロジェクトを抱えられるか」の天井として、はっきり可視化された。
寄り道：「呼ぶAI」と「住むAI」は別物だと気づいた
このあたりで、話題になっていたOpenClawを触って衝撃を受けて、けっこう価値観が揺さぶられた。エージェントがメールを読み、招待をパースして、カレンダーに書き込む。これを特別なアプリやウェブからではなく、使い慣れたチャットアプリから誰かにお願いしているような感覚でできる。やっていること自体は地味なのだけど、それを「自分がAPIを叩いて呼び出した処理」ではなく「ユーザーの環境の中に常駐しているテナントが、勝手にやった処理」として眺めたとき、頭の中で何かが切り替わった。
呼び出すソフトと、住まわせるソフトは、設計のしかたがまったく違う。呼び出すソフトは、自分が制御している。住まわせるソフトは、こちらの環境の中で生きていて、何ができて何ができないか、どこまで触っていいかを、構造として定義しておかないといけない。
一度この区別がついたあと、自分の作るプロジェクトには「これは呼ぶ系か、住む系か？」という問いが、無意識に乗るようになった。ここから先、自分のテーマはコーディングエージェントだけじゃなくなる。
フェーズ2：AIが「住める環境」を作る側に回った
ここから流れがはっきり変わった。
当時、5〜6個のプロジェクトを並行して動かしていて、それぞれでClaude Codeのセッションを走らせていた。LinuxマシンにSSHして、tmuxのペインを行ったり来たりして、なんとなく回していた。公式のDiscordプラグインがほぼ解決してくれそうだったのだけど、「ボット1つにつきセッション1つ」という縛りがあって、5プロジェクトなら5ボット。さすがにそれは違うだろう、と。
これをClaude Codeに「こういうのが困っているんだよね」と話していたら、向こうが勝手に作り始めた。3〜4時間後、Multi-Project Gateway（MPG）が動いていた。ボット1つで、Discordのチャンネルごとに別プロジェクトのディレクトリが紐づく仕組みだ。
このMPGが、自分の中でこの5ヶ月の一番の転換点だった。技術的に高度だからじゃない。地味なツールだ。ただ、これがあるとないとで「AIエージェントを使う体験」そのものが変わってしまった。6チャンネル開けば6セッションが並行で動く。SSHもtmuxも要らない。ローカル環境のお守りも要らない。
MPGがコーディングエージェントのための「場所」を整えたあと、次の問いは自然に出てきた。じゃあ、生活レイヤーにエージェントを置くとしたら、どう設計すべきか？
その答えとして作ったのがHouseholdOSだった。家族のためのGoogle Calendar / Drive / Gmail / Discordをまとめる、信頼ベースの調整レイヤー。会話形式で予定を入れたり、家族メモを保持したり、メールの仕分けをしたりする。ただし、状態を変える操作は必ず明示的な確認を挟む。家族のカレンダーにエージェントを住まわせるなら、信頼境界は「振る舞い」じゃなく「構造」で定義しないといけない。
そしてIntentLayer。エージェントがコードを書いていくと、「なぜこの決定をしたか」という人間側の意図が、だんだんコードから読み取れなくなる。それをリポジトリ内に明示的に残すためのCLIツールだ。
このフェーズで、自分の関心は完全に変わっていた。「AIと一緒に何かを作る」のではなく、「AIが使いやすくなる環境そのものを作る」。あとから知ったのだけど、これは "harness engineering" と呼ばれているらしい。
フェーズ3：「うまく協働できている」をどう測るか
エージェントを住まわせて、たくさん働いてもらえる環境ができた。そうすると次に気になるのは「これ、ちゃんとうまくいってるんだっけ？」という話だ。
Takumiは、いわば「AIアーキテクト」職の選考プラットフォーム。候補者を、技術が分からないファウンダー役のAIが「プライバシーを軽視した判断」へ誘導しようとするシナリオに置く。そして別のAIがオーディター役で、候補者がそれをちゃんと押し戻したかどうかを評価する。実際のClaude Codeセッション中の振る舞いも込みで見るためのCLI、takumi-evalもつけた。
Pulseは、自分とAIの相互作用そのものを採点するCLI。3つの軸で見る——収束（convergence）：結論に至るまでに何往復したか、意図の参照（intent anchoring）：宣言した意図にちゃんと立ち戻っているか、判断の質（decision quality）：コミットメッセージは「何をしたか」ではなく「なぜそうしたか」を書けているか。スコアリングにLLMは使わない。すべて観測可能なデータから出す。
このフェーズの目的は一貫していた。「人とAIが一緒に書いたとき、良いってどういう状態？」を、感覚じゃなく構造で語れるようにしたかった。
フェーズ4：判断を任せられるかを試す
今いま向き合っているのがAyumiだ。「個人向け生活コンテキスト・エージェント」とでも訳すような何かなのだけど、その説明だと狙いを半分くらい言い損ねる。
目指しているのは、自分のメール履歴、カレンダー履歴、書いた記事、日記、エージェントのチャット履歴、過去の判断、トレードオフの取り方を十分に取り込んだエージェントに、自分の代わりに「小さい方の判断」をしてもらうことだ。判断を「置き換える」のではなく、判断を「代理してもらう」。今の自分の認知資源を地味に消費しているけれど、本当はそこまで自分が握っている必要のない決定——そういうのを任せたい。
仕組み自体はあまり目新しくない。GmailとCalendarの履歴をトピック別（仕事、旅行、趣味、健康、社交）にカテゴリー化し、Drive（保管）上にコンテキストファイルとして保存して専門化したエージェントがアクセスできるようにする。1日に1回最新のコンテキストを取り込む処理が走る。面白いのは仕組みじゃなくて、それを何に向けようとしているかだ。
今の自分はタスクを描写すればエージェントが実行する、というところまで来ている。Ayumiで試したいのは、「次のエッセイ群のアウトラインを引け」「このプロダクトアイデアの筋を調べて、追う価値があるかを判断しろ」「このスケジュール衝突は自分が解決すべき案件か？」みたいな、もっと粗い粒度のブリーフを渡しても、それなりの結果を返してくるか、という実験だ。
これが効くなら、自分の役割そのものが一段上がる。実装者から編集者へ、編集者からディレクターへ。それが本当に望ましい終着点なのかも、そもそも到達可能なのかも、まだ答えは持っていない。Ayumiは、それを探りに行く実験だ。
振り返って見えたこと
弧をぎゅっと圧縮するとこうなる：
・フェーズ1：AIと一緒にソフトを作る
・フェーズ2：AIのための環境を作る
・フェーズ3：人とAIの協働の質を測る
・フェーズ4：判断をAIに任せる
実装者 → 環境構築者 → 観測者 → 委任者、ということになる。どれひとつ計画したわけじゃない。前のフェーズで生まれた「ひっかかり」が、次のフェーズのお題になっていった、というだけだ。
もし今からRallyHubを作り直したら、たぶん10日が3〜4日で済むと思う。モデル自体が劇的に賢くなったというより、モデルの周りの「OS」が変わったからだ。MPGがSSH/tmuxの税を消した。IntentLayerが意図をリポジトリに固定した。Pulseが「やりとりが冗長になっている」と教えてくれる。Takumiが「AI時代のスキルとは何か」を自分に問わせ続けてくれる。
このパターンは入れ子になっている。エージェントを増幅させるために作ったレイヤーが、そのまま、次に挑める仕事のレイヤーを増幅させる。これは正直、最初には全然見えていなかった。
これからまだ大きな変化の波はありそうだけど、試行錯誤するベースを作る経験ができたのはなかなか有意義な体験だったと言えそうだ。
