Research

AIQSE — ソフトウェア開発を「線」ではなく「三角形」で捉え直す提案

2026/09/20

1. なぜ「線」では品質を支えきれなくなったのか

過去50年の主要な開発方法論——ウォーターフォール、アジャイル、XP、DevOps——は、いずれも同じ土台の上にある。「要件 → 設計 → 実装 → テスト」という**パイプライン（線）**であり、常に「実装こそが高価で人間中心の中心行為であり、他の工程はそれを支援・検証するために存在する」という前提が変わらなかった。

AIは単にコーディングを速くしただけではない。コストの構造そのものを逆転させた。 かつてのボトルネックだった実装が最も安価な工程になり、かつて「オーバーヘッド」とみなされていた工程——「正しさ」とは何かを定義し、結果がそれを満たすことを証明する作業——こそが、最も高価で決定的な工程になった。

自然な最初の反応は、パイプラインを維持したまま実装者だけをAIに差し替えることだ。これがSpec-Driven Development（SDD）——仕様からAIによる実装への線である。しかしAIQSEは、この線には2つの構造的欠陥があると指摘する。

正しさが暗黙的である: 仕様はハッピーパスで何をするかを語るが、攻撃を受けたとき、負荷がかかったとき、部分的に失敗したとき、並行処理が絡んだときの振る舞いは、生成器がたまたま生成したものに委ねられてしまう
検証が循環している: 仕様から導出されたチェックを、その仕様を実装した当のエージェントが生成すれば、そのチェックは実装自身の前提——バグも含めて——を追認するだけになる

仕様を長くしても線は直らない。「正しさ」と「証明」は、同じ種類の文書の追加パラグラフではなく、別の種類の成果物だというのがAIQSEの立場だ。

2. 三角形（The Triangle）

AIQSEはパイプラインの代わりに、三角形の上に成り立つ。

                仕様 (Specification)
                何をしなければならないか
                 ╱         ╲
                ╱           ╲
               ╱  ( コード )  ╲
              ╱               ╲
     品質 (Quality) ────── 検証 (Verification)
  「正しい」とは何か         何が証明されたか

仕様（Specification）: 入力・出力・状態変化・エッジケースを含む、期待される振る舞いの正確な記述。「この仕様の独立した2つの実装が、振る舞いとして同値になりうるか」がリトマス試験紙になる
品質（Quality）: 「正しさ」を9つの明示的な次元に分解したもの（詳細は後述）。振る舞い（仕様）がハッピーパスで何をするかを語るのに対し、品質はそれ以外のすべて——攻撃下・高負荷下・部分障害下・並行処理下——で何をすべきかを語る
検証（Verification）: 仕様と品質から、実装が存在する前に導出される具体的なチェックであり、継続的に実行され、証拠として蓄積される。決定的に重要な性質は独立性であり、検証は他の2頂点から導出されるのであって、判定対象の実装そのものからは決して導出されない。「ゲージは部品からは作られない」というのが、この原則を象徴する言葉だ

コードは頂点ではない。 コードは三角形の内部で生産されるものであり、生成され、使い捨てられ、再生成される。ある実装が受け入れ可能なのは、三角形がその周りで閉じたとき——仕様が満たされ、すべての品質次元に証拠がある状態——だけである。どの頂点を人間が作り、どの頂点をAIが作るかは問わない。三角形はエージェント非依存であり、これが完全自動化を矛盾ではなく設計目標にする。

既存の方法論との違い

	形	「正しさ」の定義	検証の出どころ
TDD	ループ	テストが表明したこと	実装者自身のテスト
BDD	線	期待される振る舞い	シナリオ（品質の一次元のみ）
SDD	線	仕様に暗黙	仕様そのもの
AIQSE	三角形	明示的・9次元	品質の頂点——実装から独立

AIQSEはTDD・BDD・SDDを否定しない。それぞれが一つの真実を捉えていたと認めた上で、実装者（やがて検証者も）が機械になる世界に向けて、それらの真実を再配置する。

3. 5つの原則

品質はプロセスに作り込まれる。コードに検査で足すものではない。
三角形——仕様・品質・検証——が第一級の成果物であり、コードはその内部である。
すべての頂点はエージェント非依存である。誰が作ろうと三角形は閉じなければならない。
検証は実装から独立していなければならない。 同じ生成パスがコードとそのテストの両方を生み出すと、テストはコードの前提——バグも含めて——を継承し、検証は循環した自己確認になる
自律は、検証が強くなる速さでしか進んではならない。 トヨタが機械を無人で稼働させたのは、機械が自ら欠陥を検知して停止できるようになってから（自働化）だった。人間のチェックポイントを外すには、まずそこで自動検証が人間と同じものを捕捉できることを示さなければならない

4. 製造業の100年に学ぶ

AIQSEの土台にあるのは「ソフトウェアの実装が機械の仕事になるのは、製造業が経験した産業革命と同じ現象である」という認識だ。以下の系譜が直接輸入されている。

年代	教訓	ソフトウェアへの適用
1798年（ホイットニー）	互換部品——職人技ではなくゲージへの適合	品質モデルと検証スイートがゲージ。三角形を閉じる実装なら何でも交換可能——だから再生成が安全になる
1924年（シューハート）	品質は成果物ではなくプロセスの性質。管理図で工程を監視する	生成後の差分を1件ずつレビューするのをやめ、証拠合格率・エスケープ率・回帰の安定性そのものを計測する
1950年代（デミング）	検査では遅すぎる。欠陥の大半は労働者ではなくシステムが原因	AI生成コードの欠陥は大抵、上流（曖昧な仕様・欠けた品質次元・検証の穴）で作り込まれている。生成器を責めるのは労働者を責めるのと同じ
1950〜70年代（トヨタ）	自働化・行灯・ポカヨケ	証跡が失敗したら自律的に停止するパイプライン、年功で上書きできない停止、型・スキーマ・契約による欠陥クラスの構造的排除
現在（計測学）	信頼は職人の判断から計測器へ移った	人間の最終的な役割は、コードのレビューではなく、検証システムそのものの校正・監査
1980年代〜（無人工場）	無人工場は品質工学の放棄ではなくその卒業試験	レベル5の自律エンジニアリングは、これまでのすべての教訓が揃って初めて可能になる

歴史が警告するのは「プロセス管理より先に自動化を進めると失敗する」という点だ。独立した検証なしに自律的なコード生成を導入することは、この過ちをソフトウェアで繰り返すことに等しい。

5. 品質モデルの9次元

AIQSEの中核的な成果物が「品質モデル」である。「このソフトウェアは正しい」という曖昧な主張を、9つの明示的で個別に検証可能な次元に分解する。

Input Quality（入力品質）: 何が有効な入力で、それ以外はどうなるか
Business Quality（業務品質）: ドメインのルールと不変条件は保たれるか
State Quality（状態品質）: 操作の前後・最中で状態は一貫しているか
Security（セキュリティ）: 誰が何をしてよいか、何が漏れてはならないか
Concurrency（並行性）: 同時に複数のことが起きたときどうなるか
Performance（性能）: どれだけ速く、どれだけの量を、どのスケールで
Side Effects（副作用）: 戻り値以外に何に触れるか（外部呼び出し、通知など）
Error Handling（エラー処理）: どう失敗するか
Observability（可観測性）: 動いていることも、失敗していることも見えるか

重要なのは、品質モデルは「第二の仕様書」ではなく、仕様に散らばっている品質関連の事実を、この9軸に沿って再投影したビューだという位置づけだ。ただし単純な射影ではない。RFC 5322やセキュリティ基準、性能予算のような外部規範による補強が加わり、さらに「この次元を埋められない」という事実自体が仕様の欠落を検出したことになる——品質モデルの導出は、仕様の監査を兼ねる。この投影作業は機械的な部分が多いため、AIが草案を作り、人間がレビューする形が推奨されている。

6. 自律への6段階

三角形における人間の関与は設計ではなく、段階だとAIQSEは位置づける。運転自動化のレベル分けを意識して、職人技から自律エンジニアリングまでの6段階を定義している。

レベル	名称	人間の役割
0	職人技（Craft）	すべてを書く
1	支援付き（Assisted）	AIの提案を受けながら書く
2	指示された生成（Directed generation）	仕様と品質を定義し、証拠を判定する
3	監督された三角形（Supervised triangle）	AIが起草した頂点を承認する
4	限定された自律（Bounded autonomy）	基準を定め、例外を監査する
5	自律エンジニアリング（Autonomous engineering）	意図を表明し、システムを監査する

統治原則は明快だ。「自律は、検証が強くなる速さでしか進んではならない」。 レベルは検証システムによって獲得されるのであり、生成器の性能から推測してよいものではない。レベル2（人間が三角形を作り、AIが内部を埋める）が、現在多くのチームが実践している、あるいは到達しつつある水準とされる。品質のエスケープ（証拠が防げたはずのインシデント）が起きれば、そのドメインは自動的に1段階降格する——これは失敗ではなく、行灯（アンドン）原則が正しく機能している証だとされる。

7. 無人で回すための制御ループ

三角形とレベルは「構造」の説明にすぎない。人間がリアルタイムで見ていない状態で機械が三角形を閉じるとき、実際に何が機械的に起きるのかを定義しているのが「自律ループ」の仕様だ。ここには4つの仕組みがある。

7-1. 収束制御 — 無限ループを防ぐ

証拠チェックが失敗したとき、システムはまずなぜ失敗したかを分類してから、どこに差し戻すかを決める。「実装が悪いのか」「仕様が曖昧なのか」「品質モデルに漏れがあるのか」「検証チェック自体が壊れているのか」を切り分ける表が用意されており、これを誤ると「テストが通るまでコードを場当たり的にパッチする」という、原則4が禁じる自己確認的な循環に陥る。再試行には上限（同一チェックにつき最大3回、1つの変更につき最大8回）が明示され、上限に達したらチェックを緩めるのではなく、停止して人間にエスカレーションする。これも行灯の考え方の応用である。

7-2. メタループ — 検証システム自身を検証する

個々の失敗は1つの変更を止めるが、メタループはすべての三角形を横断して、検証システムそのものが今も信頼できるかを監視し続ける。エスケープ率、誤停止率、再試行が収束しない仕様の分布などを継続的に見張り、しきい値を超えれば当該ドメインの自律レベルを自動的に1段階引き下げる。重要なのは、メタループはレベルを引き上げる権限を持たないという設計上の非対称性だ。昇格は常に人間による意図的な意思決定であり、指標が良かったことの副作用として自動的に起きてはならない。

7-3. 判定の自動化 — 人間の承認なしに出荷してよい条件

レベル4以降では、リリース判定そのものが自動化されうる。ただしそれは、品質モデルのすべての行に証拠があり、免除された行が一つもなく、当該ドメインの自律レベルが4以上で、回帰計測がクリーンで、メタループが警戒状態でなく、かつ**「これまでに見たことのあるパターンの変更か（新規性チェック）」**をすべて同時に満たしたときだけ許される。1つでも欠ければ人間に判定が回る——これは加点方式ではなく、直列のゲート群だ。自動判定されたドメインでも、変更の最低5%（＋すべての新規パターン＋ぎりぎりで通過した変更）は事後に人間の監査対象になる。

7-4. エージェント実行 — 1回の生成パスの中の制御

コード生成を担うエージェント自身のツール呼び出しループにも規律がある。エージェントの文脈は「その変更の三角形」に限定され、「ついでにこのあたりも直しておく」といった無限定なスコープ拡大は禁止される。サブタスクの分解は、ファイルやクラスの構造ではなく品質モデルの次元ごとに行うべきとされ、エージェントが自分自身のテストを実行して次の一手を判断することは正当な作業だが、それが最終的な証拠記録に登場することは許されない——出口のゲージは常に、生成エージェントのセッションとは独立に実行される、三角形由来のスイートである。

8. 「証拠」だけが品質の主張を裏付ける

AIQSEにおける完了の定義は「マージされたPR」ではなく、品質モデルのすべての行に、合格した証拠がある状態だ。テスト結果、ベンチマーク出力、セキュリティスキャン結果、ゴールデンマスター差分、本番リプレイ結果、可観測性の表明——これらが証拠として認められる。「AIがそう言った」「見た目は正しそう」「品質モデルへの対応関係のないグリーンビルド」「行カバレッジの数字だけ」は証拠として認められない。

証拠記録は特定の実装コミットに紐づき、コードが再生成されれば古い証拠は無効になる。テストの「カバレッジ」も再定義され、コードの何行を通ったかではなく、品質モデルの何割の行に、合格した最新の証拠があるかを測る。行カバレッジ100%でも品質モデルが不完全なら、それは循環的な自己確認にすぎない。

9. 現在地：ドラフト、コメント募集中

このプロジェクトは自ら「完成した方法論ではない」と明言しており、ステータスは「ドラフト／RFC（Request for Comments）」である。三角形・9次元の品質モデル・6段階の自律レベル・自律ループの制御仕様まで、驚くほど具体的に踏み込んでいる一方、著者自身も「これらの仕組みを名指しすることと、実際に動くものを持っていることは別だ」と釘を刺している。ゴールデンマスターのコーパスやリプレイ基盤、メタループのしきい値設定といった実装投資は、多くのチームがまだ済ませていない、という限界も明記されている。

10. TIPの視点

本誌がこれまで「AIQDD」として紹介してきた4段階のパイプライン（Spec → Agentic Implementation → Governed Verification → Deploy & Observe）は、この提案が持つ「三角形」というより厳密な構造の、簡略化された紹介にとどまっていた。実際の提案は、コードを頂点から外して内部に置き直し、品質を独立した9次元のモデルとして扱い、検証の独立性を原則として明文化し、さらに自律段階を無人で回すための収束制御・メタループ・判定自動化・エージェント実行制御という4層の具体的な制御機構まで踏み込んでいる。エージェントにコードを書かせる体制を作ろうとしているチームにとって、特に「検証は実装から独立していなければならない」という原則4と、「自律は検証が強くなる速さでしか進んではならない」という原則5は、実務上すぐに点検できるチェックリストとして役立つはずだ。