03/15 19:47 2026
03/16 08:14 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と障害調査はかなり相性がいいと思っている。これはろくにo11yの設定をしてなくても最低限システム間で一意なリクエストIDを振っていれば、簡単にクエリで紐付けて統合し、一覧生成ができる。AIコーディングエージェント上でawscliを動かせば、コードの修正提案まで一気通貫でできる。DBもポートマッピングしたら、さらに幸せになれる。何が幸せって運用、障害調査の効率化は人を救うからね。
変更障害率って一瞬でAIで修正できる仮定に基づくと、ミッションクリティカルでない機能はある程度先出リリースも可能なのかなとも思ったり。まぁこういう考えはあまり好まない人多いけどね。
これはあくまでツールが提供する仕様駆動開発の話。自分はKiroしか使ったことがないのでその前提で話す。というかここに書くのは仕様駆動というよりKiroの問題な気もする。
自分はこの記事にかなり共感した。
自分は
ただAI仕様駆動ツールは発展途上で出力するドキュメントは永続的な仕様書として使うには全面書き換えが必要。これは現状実装判断まで要件として展開するため、その線引きを人間画する必要がある。これは形式言語を自然言語にしてレビューをしているような冗長さがある。永続的なドキュメントとして管理すると、コードとドキュメントの両方が詳細実装を持っており二重管理となる。
すでに実装やテストの方針が決まっているプロジェクトに置いて、作るべき実装は明確であり、そのゴールに向かってプランモードで実装する。仕様は別途Agentメモリーとは別の領域に格納するのが良い。AI駆動ツールの出力するプランやspecは永続的なドキュメントとは呼べず(これは基本設計と詳細設計の両方が一緒くたにされており、同期を取る作業が煩雑になりやすい)
上記のZennの記事は、以下のような暗黙の前提もあるように思う
開発者がコードを読める
LLMの出力を評価できる
いざ実装に入ったら市場の要件が変わっている
技術的に実現不可能な箇所が見つかる
みたいなことがあってアジャイルソフトウェア宣言には、包括的なドキュメントよりも動くソフトウェアってのがある。ただ仕様駆動はそこまでガチガチな仕組みではなくて、間違えに気づいたら仕様に戻ればいいくらいのスタンス。
仕様の永続化先をドキュメントにするとつらみとしては以下が出てくる
自分はこの生成されたSpecに問題があると思っている。LLMが膨らませた仕様は以下の問題がある。
1.に関しては、DynamoDBを使っているとDAXというかなりハイトラでない限り使わないサービスを勧めてきたりする。ちなみにこれはコンテキストに個人ブログのリプレースと入れててこの始末。まずそこに判断を要求している時点で負けだと思う。
2.に関しては、タスクごとに場当たり的にテストがある。つまり全体通したテスト戦略がないので冗長さの極みになる。
ステアリング頑張ればここら辺がこなれてくるのかな？
余談
compactionが起きるようなロングランの実装では最初に立てたプランを永続化しないとcompactionで実装計画や受け入れ条件を忘れる。なので外部化する手段としてドキュメント化は有効。
記事にある通りこういう形でドキュメントというかTODOを出力させて、長いタスクをやり切れた(Apple公証審査周りのタスク)ことがあるのでおすすめ。
