ファクト駆動開発：エージェントのワークフローを合理化する

ソフトウェア開発の展望は絶えず進化しており、コード生成からメンテナンスに至るまで、さまざまな段階でAIエージェントがますます重要な役割を果たしています。しかし、これらのエージェントを従来の開発パラダイム、特に仕様駆動（spec-driven）のアプローチに効果的に統合することは、独自の課題を提示しています。facts プロジェクトは、新しい概念である「ファクト駆動開発（facts-driven development）」を導入し、仕様の複雑さを取り除き、検証可能な「ファクト（事実）」のみに焦点を当てることで、エージェントのワークフローを簡素化することを目指しています。

この転換は、AIエージェントが冗長または複雑な仕様と対話する際に観察される非効率性を動機としています。エージェントは不要な「情報のノイズ（fluff）」を生成しやすく、また大規模プロジェクトにおける仕様の量と相互接続性は、しばしば「一貫性の税（consistency tax）」を招きます。これは、エージェントがドキュメント全体の一貫性を維持することに苦労することを意味します。facts の核心となる前提は、あらゆる仕様は、その本質において単なるファクトの集合に過ぎないということです。これらのファクトを分離して直接提示することで、開発はAIエージェントにとってより効率的になり、エラーが少なくなります。

エージェントにとっての従来の仕様駆動開発の問題点

従来の仕様書は、人間が理解し協力するために不可欠ですが、しばしば物語的な要素、手順的な指示、および暗黙的なコンテキストを含んでおり、これらがAIエージェントにとって効率的に処理することが困難な場合があります。facts の作成者である everlier は、いくつかの主要な問題を指摘しています。

• 不要な情報の生成（Fluff Generation）: エージェントに広範な仕様が与えられた場合、核心となる意図から逸脱した余計な詳細や解釈を生成してしまい、シグナルよりもノイズを増やしてしまう可能性があります。
• 一貫性の税（Consistency Tax）: 大規模プロジェクトでは、仕様は膨大かつ相互に接続されます。これらのドキュメント間の一貫性を維持することは、特に変更が発生した際に大きな負担となり、エージェントのエラーを招き、絶え間ない人間の監視を必要とします。
• メンテナンスのオーバーヘッド（Maintenance Overhead）: 詳細な仕様を最新の状態に保ち、進化するコードベースと整合性を取るために必要な労力は相当なものになり得、貴重な開発リソースを消費します。

これらの問題は、人間が理解を深めるために設計された構造そのものが、意図せずしてエージェントの操作を複雑にしている可能性があることを示唆しています。

「ファクト」とは何か、そして「仕様（Specs）」とどう違うのか？

facts のアプローチの核心は、仕様とは最終的に原子的な（atomic）検証可能な記述の集合であると仮定することです。その違いは、構造と意図にあります。

• 仕様（Specs）: しばしば冗長で物語的であり、手順的なステップ、設計上の選択、およびコンテキスト情報を含むことがあります。これらは包括的な人間の理解のために設計されており、冗長性や暗黙的な依存関係を含むことがあります。
• ファクト（Facts）: 簡潔で、宣言的であり、原子的な真実の記述です。物語的な要素は取り除かれ、検証可能な情報のみに焦点を当てます。例えば、ユーザーフローを説明する段落の代わりに、「ファクト」は「ユーザー認証には有効なメールアドレスとパスワードが必要です」や「API エンドポイント /users はユーザーオブジェクトの JSON 配列を返します」と記述するかもしれません。

あるコメント投稿者である @bgsesr42 は、「仕様とファクトのリストはどう違うのか？」と問いかけました。その違いは、主に粒度と焦点にあります。仕様はファクトを 含んで いますが、それ以上の多くのものを含んでいます。facts は、不可欠で検証可能な真実のみを抽出することを目指しており、それにより、エージェントが余計な情報を解析したり意図を推論したりすることなく、それらを消費し、行動に移すことを容易にします。

エージェントにとってよりフレンドリーな開発を実現する

仕様を個別のファクトの集合へと蒸留することで、facts プロジェクトは、AIエージェントにとって本質的に適応しやすい環境を構築することを目指しています。このアプローチには、いくつかの潜在的なメリットがあります。

• 曖昧さの軽減（Reduced Ambiguity）: 原子的なファクトは、エージェントによる誤解釈の余地を少なくし、より正確な出力をもたらします。
• 一貫性のチェックが容易（Easier Consistency Checks）: 個別のファクトの集合に対して一貫性を検証することは、複雑で物語的な仕様書を相互参照することよりも単純です。
• エージェントの集中したアクション（Focused Agentic Action）: エージェントは、これらのファクトに基づいて直接操作を行うよう指示することができ、コード生成、テスト、またはドキュメントの更新といったタスクを、必要な結果に対するより明確な理解とともに実行できます。
• メンテナンスの低下（Lower Maintenance）: 特定のファクトを更新することは、従来の仕様書の大きなセクションを修正することよりも多くの場合単純であり、エージェントにとっての「一貫性の税」を軽減します。

これを促進するために、facts プロジェクトは、エージェントがこれらのファクトと対話したり管理したりするために特別に設計された一連のスキルとコマンドラインインターフェース（CLI）を提供しています。このツール群により、エージェントはファクト駆動開発を実用的かつ統合された方法で活用できます。

前進への道：コンセプトの証明

仕様からファクトへの概念的な転換は魅力的なビジョンを提示していますが、その実用的な有効性は、採用の鍵となるでしょう。@sminchev が正しく指摘したように、具体的な証拠が必要です。

I would be happy to see some prove that this works. A project that started and went go. How a friendlier specification looks like and why agents understand it better.

実世界のプロジェクトでこのパラダイムを実証し、「よりフレンドリーな」仕様（すなわち、ファクトの集合）がどのように構造化されているかを示し、エージェントがそれらをどのように処理し、どのように恩恵を受けるかを明確な例で示すことが極めて重要です。この検証は、ファクト駆動開発が約束するエージェントのパフォーマンス、一貫性、および開発全体の効率性の目に見えるえる改善を説明するのに役立つでしょう。

結論

facts プロジェクトは、AIエージェントがワークフローに深く統合されるにつれて、最新の開発プロセスをどのように構造化すべきかという興味深い進化を表しています。冗長な仕様書への従来の依存を頼りにするのではなく、代わりに合理的なファクト駆動のアプローチを提唱することで、それはエージェントが生成する不要な情報のノイズ（fluff）や、高い一貫性の税（consistency tax）といった共通のペインポイントを解決しようとしています。プロジェクトが成熟し、実世界の実装が明らかになるにつれて、このパラダイムシフトがエージェント支援による開発の効率性をどのように再定義するかを見るのは非常にエキサイティングです。