Archive of posts from 2026-2
Addy Osmaniが2026年2月に公開した記事 How to Write a Good Spec for AI Agents は、AIコーディングエージェントに対する仕様書（spec）の設計方法を整理したものである。
彼の主張は一貫している。巨大な仕様を一度に渡すのではなく、構造化し、分割し、検証可能な形に設計することが重要である。
背景
AIに長大な仕様をそのまま与えると、次の問題が生じやすい。
- コンテキストウィンドウの制約
- 注意配分の分散
- 指示が多すぎることによるミスの増加（指示の呪い（curse of instructions）と呼ばれる）
したがって、必要なのは「網羅的な文書」ではなく、「実行可能な設計図としての仕様」である。
原則1：高レベル仕様から始める
最初は目的と成功条件を簡潔に記述し、詳細な技術仕様はAIに任せる。
手順は次の通りである。
- 目的・ユーザー体験・成功条件を記述する
- AIに詳細仕様を生成させる
- 実装前に計画をレビューする
重要なのは、実装より先に設計を固めることである。仕様は保存し、後続の作業で参照する。
原則2：構造化する
仕様は散文的なメモではなく、明確な章立てを持つ文書とする。
特に重要とされるのは次の6領域である。
- Commands（build / test / lint など実行可能なコマンド）
- Testing（テスト方法と基準）
- Project structure（ディレクトリ構成）
- Code style（サンプルコードを含む）
- Git workflow（ブランチやコミットの規則）
- Boundaries（操作制限）：「Always / Ask first / Never」の三層で定義する
仕様は固定文書ではなく、更新され続ける「生きた文書」として扱う。
原則3：タスクを分割する
すべてを一度に処理させるのではなく、作業を小さく分割する。
- 一度に一つの課題に集中させる
- 必要な文脈のみを与える
- 完了後に検証し、次へ進む
仕様が長い場合は、目次を作り、必要な箇所だけ参照させる方法が推奨されている。これにより、コンテキスト消費を抑えつつ全体像を保持できる。
原則4：自己検証と制約を組み込む
仕様は実装指示だけでなく、品質管理の仕組みでもある。
有効な手法として次が挙げられる。
- 実装後に仕様項目との照合を行う
- テストやlintを必須化する
- 別プロンプトでレビューを行う（LLM-as-a-Judge）
- 仕様由来の適合テストを用意する
また、ドメイン特有の知識や既知の落とし穴を仕様に明示することで、出力の精度が向上する。
原則5：反復と更新を前提とする
仕様は一度書いて終わるものではない。
- 実装で誤解が生じた場合は仕様を更新する
- 仕様をバージョン管理する
- 「Spec → 実装 → テスト → 修正」の循環を維持する
AIの速度や非決定性を前提に、検証工程を組み込むことが必要である。
この対談では、アジャイル25周年のイベントにおいて、AI時代に「何が変わり、何が変わらないか」が議論されている。
- 変わらない重要な原則：小さく段階的に進める開発、テストと検証、持続可能なペースといった従来のアジャイルの基本は、AIによってコード生成量が増える今こそ、むしろ重要性が増している。
- コード品質と可読性：AIがコードを読めるとしても、人やAIが理解できるコードを維持すべき。コード生成自体は多くの組織にとってボトルネックではなく、品質管理と検証が課題。
- 既存システムへのAI活用：AIやLLMはグリーンフィールド開発だけでなく、巨大で複雑な既存コードベースの理解、ナビゲーション、改善に特に有効。多くの企業顧客にとって現実的な価値がある。
- 新しい可能性と根本的問い：エージェントによる既存システムの修復・進化、ソースコードやコードレビューは本当に必要か、などの根本的な問いが出ている。ただし、それらが解決してきた問題は、AIで消えるどころか、悪化する可能性もある。
- レガシー増大への懸念：コード生成が容易になることで、理解不能なコードやレガシーが増えるリスクがある。そこで、システムを「価値とリスク」で層別化し、重要部分に設計品質を集中させ、重要度の低い部分ではある程度のエントロピーを許容する考え方が提案されている。
- スピードと持続可能性のバランス：速すぎる開発は後の大規模な後始末につながりやすい。AIは散らかったものを片付けることはできるが、最初から持続可能なペースで進めるほうが望ましい、という認識で締めくくられている。
AIは技術的変化か？
ファウラーは、AIは自身のキャリアで「最大の技術的変化」だと述べている。歴史的に比較できるのは、アセンブリ言語から高級言語への移行程度だという。
ただし、重要なのは抽象度の上昇そのものではない。
- 同じ入力でも異なる出力が得られる
- 自信を持って誤った結果を返すことがある
- 実行結果を完全には再現できない
この性質は、従来のソフトウェア工学が前提としてきた決定論的モデルとは大きく異なる。
したがって、テスト、レビュー、セキュリティ、品質保証の考え方を再検討する必要がある。
Vibe Codingに対する見解
ファウラーは「Vibe Coding」を、生成されたコードをほぼ読まず、理解もしない使い方として定義している。
適している用途
- 探索的な試行
- 使い捨てのプロトタイプ
- 短期間のみ使うツール
問題点
最大の問題は、学習ループが失われる点にある。
- コードを読まない
- なぜ動くのかを理解しない
- 修正や進化ができない
結果として、少しの変更でも再生成に頼ることになり、長期的な保守には向かない。
実際に有効とされているAI活用
対談では、実用性が高いと評価されている使い方も具体的に挙げられている。
- 高速なプロトタイピング
- 短期間で複数の案を試し、方向性を探る用途。
- レガシーコードの理解：
- コードを解析し構造情報を抽出
- 依存関係をグラフとして扱う
- LLMを使って問い合わせる
- 未知の技術やドメインの学習
- 新しい言語、フレームワーク、業務分野を理解するための探索用途。
未解決の課題
以下の点はまだ確立した方法がないとされている。
- 既存コードの安全な変更
- 大規模リファクタリング
- チーム開発での使い方
- コードレビュー負荷の増大
LLMは「非常に生産的だが信用できない同僚」に例えられている。
リファクタリングの位置づけ
AIによってコード生成量が増えるほど、リファクタリングの重要性は増す。
- 振る舞いを変えない
- 小さなステップで行う
- 構造を改善する
という従来の考え方は、AI時代でも有効であり続ける。
アジャイルとの関係
AIが導入されても、アジャイルの基本原則は変わらない。
- 小さな変更
- 短いフィードバックループ
- 人間による確認
量を増やすよりも、サイクルタイムを短くすることが重要だとされている。
若手エンジニアへの助言
若手に対しては次の点が強調されている。
- AIは使うべきだが信用しすぎない
- なぜそうなるのかを問い続ける
- 良いメンターを見つけることが重要
AIは教師ではなく、過去の情報の集約にすぎない。
業界全体の見方
現在のテック業界の停滞やレイオフの主因は、AIそのものではなく金利上昇と投資環境の変化にあるとされている。長期的にはソフトウェア需要は続き、AIは仕事を減らすというより、仕事の進め方を変える存在だと位置づけられている。
橘玲著『HACK（ハック）』で紹介されていたので見たんだけど、本当にやばい映画だった。
中国の有能なプログラマーたちが高収入の目を奪われて海外に行くが、そのまま集団で誘拐され、オンラインカジノの詐欺の片棒をかつぐことになる、という話。もうひとりの主人公はモデルの女性で、同じように騙されて海外まで連れてこられ、オンラインカジノのディーラーとして売上を達成するまで帰国できないことになっている。彼らは何度も逃亡を図ろうとするが、いつもうまくいかずに拷問されてしまう……。
近年、中国のセレブやインフルエンサーが誘拐されたり、日本の若者が東南アジアに連れて行かれて犯罪に巻き込まれたりと、映画と同じようなニュースを何度も耳にする。本当に本当に本当に本当に、気を付けてほしい。
映画では場面が転換して、今度はオンラインカジノの詐欺に騙される中国の若者にフォーカスがあたる。プログラムで勝ち負けをうまくコントロールされているため、自然とギャンブル依存症になり、借金を余儀なくされ、最終的には自滅の道を進んでいく……。最後には、このような詐欺に騙されないようにと、警察から映画の視聴者に向けて啓蒙する内容になっている。
なお、詐欺の拠点はタイ、ミャンマー、カンボジアあたりだとされているらしく、各国からイメージが悪くなると抗議の声があがっていたらしい。実際、中国からの旅行者が減ったとかなんとか。
登場人物は少なく、物語はシンプルで、すごい犯罪というわけでもなく。でも、主人公にふりかかる悲劇だけはあまり見ない感じかなあ。にしても、ふつうにソファに座ってられるもんかね。
田邊和也さんという役者さんをはじめて見たけど、イカついなー。
プリクラのあるゲーセンで繰り広げられる、地元ローカルの「紗々」のような人間関係を描いたもの。ワードセンスに惹かれて好きになったけど、それは本当にその人に帰属するセンスなのか？という問いかけから、いろんな人からいいところを吸収して、BEAMSみたいにセレクトショップになればいいじゃん！っていう答え。若いうちはこういうのでいいんだよ、こういうので。
ただ、引用される固有名詞がこの世代に特化してるので、（私のような）おじさんにはちょっとウケが悪いかも。それでも「共有から3番目」くらいはわかったよ。世代を問わない普遍的なネタはすごくおもしろかった。
なんだか人気らしいので見てきたけど、雰囲気だけの映画だった。久しぶりに戻ってきた映画監督の父親が、娘を題材にして映画を撮ることで、いろいろ浄化していく、みたいな。あれこれ明確に語れるわけではないので不親切。が、そういうのを「雰囲気のまま」味わうことが大事なのかもしれん。別に悪い雰囲気ではなかったし。にしてもなあ。
蓮見翔さんが岸田國士戯曲賞を受賞されたということで、過去の演劇公演が再配信されていたので、早速視聴した。同時に同じタイトルの第2回も配信されている。が、あまり音質がよくないので、単に内容を知りたいだけなら第6回だけを見ればいい（他の理由があるなら両方見ればいい）。
動画配信サイトの登場により廃れつつあるレンタルDVD屋を舞台にして、新しい男女関係（配信サイト）と忘れ去られる男女関係（レンタル屋）を対比して描く、というもの。とてもおもしろかった。あと、変な人（忽那）も描かれている。忽那の変な人の演技は大変すばらしいな！
ダウ90000は固有名詞を登場させるのが特徴だが、評価を下げるだけの東京靴流通センターとか大丈夫なんだろうか？
「若者文化」って感じ。VR、VTuber、ゲーム等に馴染みのないおじさんにはキツかった。が、映像は本当にすごいな！こんなのができるんだって感じ。
前から見たかったこともあるけど、いま計算機の歴史みたいな本を翻訳しているので、ちょうどいいタイミングだなあと思って見た。マーキュリー計画に携わった3人の黒人女性を描いた作品。
冒頭から「同じ建物に非白人のトイレがない」という胸糞悪くなるような描写で、才能が重視されるNASA（NACA）であっても、当時は才能以外の部分で評価されていたという状況を嫌と言うほどわからされる。他の2人についても「昇進の条件を満たすには白人の学校に通う必要がある」だったり、「管理職相当の働きをしていても黒人は管理職にはなれない」だったりと、理不尽な現実を突きつけられる。
とはいえ、物語としては非常に素直な流れになっている。そうした厳しい現実に屈することなく、仕事もプライベートも充実させながら、力強く生きていく主人公たちの生き様が描かれている。そして、上記の問題は本人たちの努力や周囲の尽力で解決され、最終的にはマーキュリー計画が成功して終わる。すばらしい作品。
最終的に管理職になる女性（ドロシー・ヴォーン）は、図書館から盗んでいた本（税金で買ったものだから私のもの理論!!笑、書籍は架空のものっぽい）でFORTRANを勉強して、IBM 7090の使い方を勝手に覚えて、さらには手計算をしていた部下たちにもFORTRANを学ばせて、IBM部隊のマネージャーになっていた。
Wikipediaを見ると、映画なのでいろいろ脚色があるようだが、それを差し引いても当時のことを感じられるよい作品でした！