AI エージェントと開発したこと

このプロジェクトでの AI 活用#

yatamux は AI コーディングエージェントをかなり前提にして育ててきたプロジェクトだ。 主な用途は「大量実装を丸投げすること」よりも、 既存コードの読解、Windows API 周辺の調査、回帰を避けるためのテスト雛形づくりにある。

現在のリポジトリにも、その前提が残っている。

• task.md: 直近の実装メモ
• CLAUDE.md: 継続的に使う開発ルール
• docs/tasks/active.md: 作業中タスクの整理
• docs/test-plan-*.md: 実機確認が必要な機能の手順書

いまの開発フロー#

1. まずタスクを外部化する#

会話の中だけで要件を持つと、長い修正で前提が崩れやすい。 そこで先に task.md や docs/tasks/active.md に要件を書く。

良かった書き方は、次の 3 点を必ず分けることだった。

• 前提
• 操作
• 期待結果

これだけで、エージェントに「何がバグで何が仕様か」を渡しやすくなる。

2. 実装前にコード上の入口を特定する#

たとえば「send-keys --wait-for-prompt が不安定」という相談なら、 今の repo では最低でも次を見る必要がある。

• src/cli.rs
• crates/protocol/src/message.rs
• crates/server/src/pane.rs
• crates/terminal/src/vt/osc.rs

AI に価値があるのは、こうした横断検索を高速に回せる点だ。

3. テストと手動確認を分けて考える#

このプロジェクトは Win32 / IME / ConPTY を含むので、 自動テストだけでは不十分な箇所が多い。

そのため現在は二段構えになっている。

• ユニット / 統合テストでロジックを固定する
• docs/test-plan-*.md で実機確認手順を残す

AI に依頼するときも、「どこまでが自動テストで守れて、どこから先は手動確認か」を 最初に明示した方がぶれにくい。

4. 変更の理由をセットで渡す#

「リファクタして」だけでは広がりすぎる。 一方で理由を添えると、変更範囲がかなり安定する。

例:

PaneStore に UI 状態が集まりすぎているので分離したい、ではなく、
layout_switch の責務だけを app 側で閉じたい。既存のキー入力経路は壊さないこと。

このレベルまで意図を書くと、エージェントが不要な抽象化を持ち込みにくい。

AI を使っていて有効だった原則#

一次情報を先に読む#

Windows API や crate の仕様は古い記憶に引っ張られやすい。 そのため設計判断の前には必ず次を確認する。

• 現行ソースコード
• 公式ドキュメント
• 既存テスト

これは人間にも AI にも同じで、推測のまま進めると Win32 周りは特に危ない。

「生成」より「読解」の負荷を下げる#

このプロジェクトで本当に重いのは、Win32、VT、非同期処理、CJK 幅計算が 別レイヤに分かれていることだ。 AI はこの複数レイヤをまたいで「今のコードはどこで責務が切れているか」を 整理させる用途で効きやすい。

会話の記憶に頼りすぎない#

長い会話の途中で仕様がねじれるのは珍しくない。 だからこそ CLAUDE.md、task.md、テスト、設計メモを repo に残している。

AI と開発するときの実感としては、 会話の質より 外部化したコンテキストの質 の方が重要だった。

現実的な分業#

タスク	人間 / AI
何を作るか決める	人間
既存コードの探索	AI が得意
Win32 API の当たりを付ける	AI が得意
最終設計判断	人間
回帰ポイントの洗い出し	人間 + AI
実機確認	人間

AI がいても、IME や通知やフォーカス周りの最終確認は実機で見るしかない。 逆に、その前段の「怪しい地点を絞る」部分はかなり任せられる。

まとめ#

yatamux のように、Windows ネイティブ UI と terminal emulation が交差するコードベースでは、 AI の価値は速度そのものよりも 探索コストの圧縮 にある。

設計メモ、テスト、確認手順を repo に残しておくと、 その探索を毎回ゼロからやり直さずに済む。