最近のAIコーディングエージェント周りの話
03/15 19:47 2026
03/15 19:51 2026
はじめに
最近のAIコーディングエージェント周りの個人的興味メモ
ハーネスエンジニアリング
「ハーネスエンジニアリング」という言葉をAI・ソフトウェア文脈で最初に使ったのはMitchell Hashimotoで、このブログが元ネタだと思う。
I don't know if there is a broad industry-accepted term for this yet, but I've grown to calling this 'harness engineering.' It is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again.
業界で広く認められている名称がまだあるのかは分かりませんが、私はこれを「ハーネス・エンジニアリング（安全装置の設計）」と呼ぶようになりました。これは、エージェントがミスをしたときはいつでも、そのミスを二度と繰り返さないための解決策を時間をかけて構築していくという考え方です。
gogcli入れるか迷っていたところに公式サポートはない公式ツールという謎の立ち位置でリリースされたGoogle Workspace CLIのリリースをきっかけに、昨年頭にうまくいかずやめていた開発以外の業務システム自動化を試している。
MCPが出てきたばかりの頃にGoogle Calendar MCPで仕事稼働管理をさせていたんだけど、ものすごいオーバーヘッドがあって、フィードバックサイクルを回すのが苦痛だった。
やはり業務システムの癖に合わせてスキルをチューニングする幅がある。でもこれをエンジニアリングと呼べるかというとそうでもない。雑に作らせて、筋の悪いアプローチはやめさせて、実践投入して失敗させて改善させるという繰り返し。これは現場の数だけやる必要がある。ただ一方でモデルの進化によってその工数は激減するし、ミクロな自動化は専門性もクソもなくAIに投げて、振る舞いダメなら改善促せば終わる世界だなと思う。
とはいえこれがクラウドから障害を検知してコードベースにPRを送る仕組みならある程度専門性というか、IT知識がないと大変なことになる。Amazonもここら辺試しているっぽく、一方で障害も起きており興味深い出来事だと感じた。
プロジェクトとか業務に合わせてハーネスをチューニングする仕事はAI時代の新しい仕事だなとはおもう。
運用とLLM
LLMと障害調査はかなり相性がいいと思っている。これはろくにo11yの設定をしてなくても最低限システム間で一意なリクエストIDを振っていれば、簡単にクエリで紐付けて統合し、一覧生成ができる。AIコーディングエージェント上でawscliを動かせば、コードの修正提案まで一気通貫でできる。DBもポートマッピングしたら、さらに幸せになれる。何が幸せって運用、障害調査の効率化は人を救うからね。
変更障害率って一瞬でAIで修正できる仮定に基づくと、ミッションクリティカルでない機能はある程度先出リリースも可能なのかなとも思ったり。まぁこういう考えはあまり好まない人多いけどね。
AIコーディングエージェントの提供する仕様駆動機能
これはあくまでツールが提供する仕様駆動開発の話。自分はKiroしか使ったことがないのでその前提で話す。というかここに書くのは仕様駆動というよりKiroの問題な気もする。
自分はこの記事にかなり共感した。
このような暗黙の前提もあるように思う
- 開発者がコードを読める
- LLMの出力を評価できる
ウォーターフォール開発では仕様書が完璧になるまでコードを書き始めないという開発プロセスで
- いざ実装に入ったら市場の要件が変わっている
- 技術的に実現不可能な箇所が見つかる
みたいなことがあってアジャイルソフトウェア宣言には、包括的なドキュメントよりも動くソフトウェアってのがある。ただ仕様駆動はそこまでガチガチな仕組みではなくて、間違えに気づいたら仕様に戻ればいいくらいのスタンス。
仕様の永続化先をドキュメントにするとつらみとしては以下が出てくる
- 生成されたSpecのレビューが必要
- 仕様と実装の2重管理が必要
自分はこの生成されたSpecに問題があると思っている。LLMが膨らませた仕様は以下の問題がある。
- ユーザー固有の文脈が一般論に希釈されたもので社内とか現場のナレッジから離れているケースが多い
- テスト実装が冗長になりがち
1.に関しては、DynamoDBを使っているとDAXというかなりハイトラでない限り使わないサービスを勧めてきたりする。ちなみにこれはコンテキストに個人ブログのリプレースと入れててこの始末。まずそこに判断を要求している時点で負けだと思う。
2.に関しては、タスクごとに場当たり的にテストがある。つまり全体通したテスト戦略がないので冗長さの極みになる。
ステアリング頑張ればここら辺がこなれてくるのかな？
余談
compactionが起きるようなロングランの実装では最初に立てたプランを永続化しないとcompactionで実装計画や受け入れ条件を忘れる。なので外部化する手段としてドキュメント化は有効。
記事にある通りこういう形でドキュメントというかTODOを出力させて、長いタスクをやり切れた(Apple公証審査周りのタスク)ことがあるのでおすすめ。
shuntaka.dev
This site uses Google Analytics.