AI時代の開発プロジェクトにおいて、ボトルネックは何か？

はじめに

AIがこれだけ広く、当たり前に使われるようになり、私たちの開発プロジェクトにも入り込んできました。その結果、プロジェクトの性質――とりわけ「どこがボトルネック（制約条件）になるのか」が、従来から大きく変わってきていると感じています。

言うまでもなく、ボトルネックはプロジェクトを進めるうえで決定的に重要です。制約理論（Theory of Constraints）が言うように、システム全体のスループットは、いちばん細い部分＝ボトルネックによって決まります¹。いくらAIで個々の作業が速くなっても、ボトルネックが解消されない限りプロジェクト全体の生産性は上がりません。逆に言えば、そこが詰まればプロジェクト全体が遅延する、というリスクの所在でもあります。

そこで今日は、AI時代の開発プロジェクトでボトルネックになっているのは何か、そしてそれを解消するにはどんな方法があり得るかについてお話しします。

最初にお断りしておくと、これは「実際にうまくいきました」という成功談ではありません。私自身もまだ考えている途中で、あくまで思考実験であり、理想論です。これからAI時代の開発に私たちが適合していくうえで直面する問題を考える、その議論のきっかけになればという気持ちで話します。私の言うことには誤りや勘違いも多々含まれているかもしれません。それも含めて、たたき台として受け取っていただければ幸いです。

結論：要件定義とレビューがボトルネックになる

冒頭の問い――AI時代の開発プロジェクトでボトルネックは何か――に対する私の結論は、「人間の判断」 です。

人間の判断が必要になるのは、SDLC――ソフトウェアを作る工程――の内部でいうと、大きく要件定義とレビューの2か所だと考えています。

これだけAIが賢くなり、設計・実装・テストといった作業が劇的に効率化・高速化されても、要件定義やレビューで人間が判断する部分はやはり残り続けます。そして、その部分がボトルネックになる――これは、後述する待ち行列の構造から理屈のうえでも導けますし、AI駆動開発を現場でやっている方の体感とも一致するのではないかと思います²。

なぜ人間がボトルネックになるのか

では、なぜ人間がボトルネックになるのでしょうか。一見当たり前のことのようですが、ここで一度立ち止まって整理しておきます。

理由はAIのコストと並列性にあります。いまやAIの推論コストは大きく下がり、多くの場面で、開発者一人の人件費よりエージェントを動かすコストのほうが安く済みます³。そして何より、お金を惜しまなければいくらでも並列に増やせる。だからAIが担う設計や実装の作業は、どんどん並列化して高速に進められます（もちろん、モデルの選択やタスクの性質、使い方によってコストは大きく変わります。ここでの肝は「安い」ことよりむしろ「並列に増やせる」ことです）。

一方で、レビュー――とりわけ最終的な品質判断の責任――は人間に残ります。AIに一次レビューをさせること自体はできますが、その結果を引き受けて「これでよし」と承認する判断は、いまのところ人間に残る。すると、高速に量産されてくる成果物に対して、人間という限られた窓口の前に待ち行列が発生します。待ち行列理論が教えるとおり、速い生産者が単一の遅い処理窓口にどんどん仕事を流し込めば、待ち時間は跳ね上がります（処理窓口の稼働率が上限に近づくほど、待ち時間は急激に伸びる）⁴。これがボトルネックの正体です。

人間が担うのは、先ほど述べたとおり大きく2つです。一つは何を作るか（意図・要件）を決めること（要件定義）――人間が起点となる発案です。もう一つはその意図に照らして、AIが生成したもの（設計・実装・テスト、そして設計判断そのもの）が正しいかを判定すること（レビュー）――AIの出力を承認したり差し戻したりする評価です。

今日はこのうち、要件定義はいったん脇に置き、レビューに焦点を当てます。レビューのボトルネックをどう解消すればよいのか、そこを中心にお話しします。

レビューのボトルネックを解消する3つの方法

レビューのボトルネックを解消する方法は、大きく3つあると考えています。

1. 人間のレビュワーの数を増やす
2. 一人あたりのレビューを速く捌けるようにする（レビュー負荷を下げる／レビュー能力を上げる）
3. そもそもレビューすべき範囲を狭める（別の方法で打ち取る）

1つ目「レビュワーの数を増やす」 は、最も分かりやすい解決策です。待ち行列は窓口を増やせば速く捌ける、というのは常識的な対応でしょう。

2つ目「一人あたりのレビューを速く捌けるようにする」 には、二つの方向があります。一つは一人ひとりのレビュー能力そのものを上げること。もう一つはレビューの負荷を下げる工夫をすることです。後者の例としては、レビューしやすいダッシュボードを用意する、あるいはAIの出力が人間にとって読みづらいのであれば、それを読みやすい形に変換する仕組みを作る、といったやり方が考えられます。

ただ、方法1と2には共通の限界があります。どちらも 「希少な人間のレビュー能力」を増やす／磨く 方向であり、効果は人間という資源の量に対して線形にしか伸びません。人間は希少資源ですから、頭数をどんどん増やすのも、一人の処理速度を上げ続けるのも、いずれ頭打ちになります。

これに対して3つ目「レビューすべき範囲を狭める」 は、毛色が違います。これは人間の能力を増やすのではなく、そもそも人間がレビューしなければならない対象を減らす――待ち行列に並ぶ仕事の量そのものを構造的に削る方向です。だから私は、3つのなかでこれが最も費用対効果が高いのではないかと考えています。あくまで私の見立てですが、人間という制約に対して線形にしか効かない方法1・2より、制約にかかる負荷そのものを減らす方法3のほうが、効きが大きいと見ています。

具体的には、静的解析や自動テストなど、機械的・決定論的なプログラムで処理できる部分はそちらで処理するということです。

つまり、こういう発想です――仕様やテストケースが正しいかどうかは人間がレビューする。そのテストに通る形で実装ができていれば、実装を一行ずつ人間が読む必要は大きく減らせる。 こうしてレビュー対象を絞り込む。

――ただし、制約理論が教えるとおり、ボトルネックは解消すると消えてなくなるのではなく、次に遅い工程へ移動します¹。レビュー範囲をテストで狭めても、こんどは「そのテストや仕様自体が正しいか」を人間がレビューする必要が残る。つまりボトルネックは消えません。変わるのはレビューの"対象"です――「AIが量産した実装すべて」から、「人間の意図を表す、より小さく安定した面」へと移る。狙いはボトルネックを消すことではなく、AIに委譲できる領域を広げ、人間の責務より小さな面へ移すことにあります。では、その「小さな面」をどう作るのか。それが次の話です。

AI時代のテスト手法

人間がやらないとどうしようもない部分は、繰り返しになりますが、何を作るかを決めることと、機械的には判定できない正しさ――たとえば設計判断の良し悪し――を見極めることです。逆に言えば、要件や仕様に関する判断が関わるテストを自動化できれば、人間がレビューすべき範囲をかなり狭められるはずです。

以下、その観点から3種類のテストを順に見ていきます。これらは「人間の意図がどこに宿るか」で分けた3つの面――シナリオ・普遍条件・設計判断――に対応しています。

① E2Eテスト（シナリオテスト）

まず最初にやりたくなるのがシナリオテストです。いわゆる総合テストや受け入れテストにあたるものです。

最終的にユーザーが実際の業務でシステムを使う場面を想定し、そのシナリオのなかでシステムが自分の意図したとおりに動くか、現実においてちゃんと役に立つ形で機能するかを確かめる――それがシナリオテストです。これを書くことで、必要な要件の見落としがないかを確認でき、同時に要件どおりにシステムが動くかも検証できます。

ここで具体例を一つ。私が個人的に作っている Moira（モイラ）というプロジェクト管理システム⁵では、受け入れシナリオを次のような「振る舞い（When / Then）」と「画面の変化（Before → After）」の形で書き起こしています。

たとえば「進行中のタスクを『もう不要』として、正直にキャンセルする（達成率100%に偽装してクローズしない）」というシナリオは、こう書きます。

振る舞い（When / Then）

When  開発者が、進行中のタスク T を「もう不要」と判断し、理由を付けてキャンセルする
Then  T はアクティブな一覧（作業キュー・レビューキュー・未割当バックログ）から消える
And   T は「キャンセルされた（やらなくてよい・理由付き）」と画面で明確に分かり、
      終端であって、後からまた現れない
And   すでに費やした分（3人日）は『100%偽装』にされず、実コストとして正直に残る
      （出来高（EV）は増えない）
And   T は削除されず、誰がいつ何の理由でキャンセルしたかが履歴に残る

画面の変化（Before → After）

項目	Before（キャンセル前）	After（キャンセル後）
実装タスクT（進行中・3人日消費済み）	「進行中」と表示	「キャンセル（理由付き）」と表示され、各キューから消える
出来高（EV：達成した価値）	—	増えない（「とりあえず100%にしてクローズ」をしない）
実コスト（費やした3人日）	計上済み	そのまま残る（コストは事実だから消さない）

ポイントは役割分担です。人間は、この「振る舞い」と「画面の変化」をレビューするだけでよい。 「うん、キャンセルしたらこう動いてほしい」と意図どおりか確認する。そして、これを実際のE2E自動テストに書き起こし、実行してグリーンになるか確かめる作業はAIに任せる――こうしたすみ分けができるのではないか、という話です。これによって、人間がレビューすべき範囲は確実に狭まります。

ここで一つ、「シナリオは人間がレビューして意図どおりだと確認できたとして、AIがそのシナリオを正確に反映した自動テストを書けるのか、本当に信頼できるのか？」という疑問を持つ方もいると思います。これはもっともな疑問です。

私の見解はこうです。シナリオを考える作業は、現実の業務とシステムをつなぐ「橋渡し」であり、システムの振る舞いが妥当かどうかを見極める作業です。ここは人間にしかできません。一方で、いったん固まったシナリオをテストコードに落とす作業は、自然言語の意図を実行可能な形へ写し取る作業で、比較的AIが力を発揮しやすいところです。

ただし――ここが大事なのですが――「信頼してよい」は「検証を捨ててよい」という意味ではありません。

まず、「信頼してよい」理由は、E2Eテストには機械的な歯止めがあるからです。AIが書いたテストは実システムに対して実際に走り、グリーン/レッドが出ます。翻訳をしくじれば、多くの場合テストが落ちて気づける。この「実行して確かめられる」点が、AIの推論が介在する照合より信頼を置きやすい理由です。

一方、「検証を捨ててよい」とならないのは、それでもテストがグリーンでも間違っていることはあるからです。空回りする（何も検証していない）アサーションを書いてしまう、そもそも仕様の一部をテストし忘れる――こうした取りこぼしは起こります。テストはバグの存在を示せても、不在を証明することはできません⁶。だから実務では、AIが書いたテストやプロパティそれ自体を、別のエージェントの敵対的レビューや人間のレビューにかける。これが現実的な落としどころだと考えています。

② プロパティベーステスト

では、E2Eテストを書けばそれで十分かというと、まだまだ不十分です。

E2Eテストは、しょせん具体的なシナリオの寄せ集めです。具体例を有限個並べるアプローチである以上、入力の組み合わせを網羅し尽くすことはできません。

では、シナリオテストだけだとどんなケースを見逃すのか。それは、システムが持つべき普遍的な条件――どんなシナリオであっても必ず成り立っていなければならない、前提条件のようなもの――です。これはE2Eテストでは確認しきれません。

たとえば Moira には、こんな普遍条件があります⁵。

• 「達成率（EV%）は、必ず 0〜100% の範囲に収まる」。
• 「イベントの記録順を入れ替えても、導出される結果はまったく同じになる」（同じ時刻・同じIDの並びを保つかぎり）。

こうした性質は、特定のシナリオをいくら積み上げても確かめきれません。シナリオテストは「タスクをキャンセルしたら達成率が上がる」といった一つの具体例を検証するものですが、「どんな入力の組み合わせでも達成率が100%を超えない」ことや、「記録の順番によらず結果が一意に決まる」ことは、その守備範囲の外にあるのです。だから見落とす。

この問題への解決策が、プロパティベーステスト（Property-based Testing） です。

これまで私たちが慣れ親しんできた機能テストは、基本的にエグザンプル（具体例）ベースのテストです。両者の違いはこうです。

	エグザンプルベース（従来の機能テスト）	プロパティベース
何を書くか	具体的な入力を一つ用意し、その出力が期待値と一致するか確かめる	「どんな入力でも成り立つべき性質（プロパティ）」を宣言する
例	「AをしてBをしたら、結果はこの値」	「どんな操作をしても、達成率は必ず0〜100%に収まる」
入力	人が手で用意した数例だけ	フレームワークが自動で大量にランダム生成して試す
強み	分かりやすく、書きやすい	人が思いつかない組み合わせ（順序の入れ替えや極端な値）まで探索し、反例が見つかれば最小化して示す
弱み	用意した一例しか踏めない＝想像の範囲しかテストできない	「成り立つべき普遍条件」を抽出するのが難しい

エグザンプルベースのテストは、結局のところエンジニアが想像できた範囲しか確かめられません。これに対しプロパティベーステストは、人間が見落とすような入力の組み合わせまで自動で突いてくれる。だからこそ、シナリオテストの穴を埋められるのです。

強調しておきたいのは、E2EテストとPBTはどちらか一方で足りるものではなく、相補的だということです。E2Eは「特定の現実シナリオで妥当か」を、PBTは「あらゆる場合に普遍条件が破れないか」を見る。守備範囲が違うので、両方が要ります。

なお補足すると、プロパティベーステストはAI時代に生まれた新しい手法ではなく、20年以上前からある考え方です（PBTのフレームワークとして広く知られる QuickCheck の論文は2000年の発表です）⁷。ではなぜこれまで爆発的には普及しなかったかというと、理由の一つが 「システムの普遍条件を人間が抽出する」という作業の難しさ でした（ほかにも、テストデータ生成器の設計の難しさなど、障壁はいくつかあります）⁸。

その「普遍条件の抽出」は、AIが提案を助けやすい作業でもあります。だから、AIをうまく使えばこれまでの障壁の一つは下げられるのではないか――そう考えています⁹。ただし、ここでも「信頼するが検証する」は同じです。AIが普遍条件を提案できることと、それが正しい普遍条件であることは別問題なので、AIが起案したプロパティはやはり人間が一つずつレビューして承認します。AIによってPBTがやりやすくなる、という見立て自体は、まだ私にとって仮説の段階でこれから実証する必要があると考えています。

③ 設計判断の検証

ここまでで、プロパティベーステストによってシステムの普遍条件を、シナリオテストによって現実の業務に接地する有限のシナリオを、それぞれ検証できました。では、これで十分でしょうか。残念ながら、これでもまだ取りこぼす領域があります。

それが設計判断です。

機能テストやシナリオテストでは、たとえば「保守性の高いシステムにするために、こういう設計方針で進めよう」と決めた部分は検証できません。システムは、その設計判断を守っていても守っていなくても、機能としては同じように動いてしまうからです。

Moira を例にとります⁵。Moira には「計算の『土台』と『計算そのもの』を分ける」という最上位の設計原則があります。土台（システムの中核）は「構造・不変条件・仕組み」だけを持ち、「評価・値・計算式」はすべて下流に持たせる、という方針です。これを守らないと、同じ指標が複数の場所で別々に計算され、いわゆる 「二つの真実」 が生まれてしまいます。

しかし――この方針が守られているかどうかは、シナリオテストでは分かりません。 画面に出る数字が正しいかどうかはテストできても、その数字が「土台で一度だけ計算されたもの」なのか「画面側でこっそり再計算されたもの」なのかは、振る舞いテストからは見えないのです。

そして、この設計判断のなかにも、自動テストにできるものと、できないものがあります。

自動テストにできる設計判断の例：

• 「土台は下流の計算に依存してはならない」（先ほどの設計原則）。これは、依存関係を機械的にチェックするアーキテクチャ適合性テスト（fitness関数） で打ち取れます。Moira では静的解析ツールを使い、「循環依存の禁止」や「土台が計算側を取り込まない」といった依存方向のルールをCIで実際に動かしています（現状はまだ素朴な代理ルールの段階で、本格的な境界の強制はこれからですが、方向としてはこれです）。
• 「記録は追記専用で、過去を書き換えない／削除APIを持たない／イベントの種類は4つだけ」。このうち「削除APIを持たないこと」「イベント種別が4つに固定されていること」は型テストで機械的に保証できます。さらに「過去を書き換えず、同じ記録なら同じ結果が再現される（追記専用）」という性質は、先ほどのプロパティベーステストで確かめます（記録の順を変えても結果が変わらない、という性質がまさにこれです）。

これらは理想を言えば、すべて自動テストにしてしまうべきだと思っています。

自動テストにしづらい設計判断の例：

• 「人のスキルや習熟度をモデル化しない（誰がどのタスクをやるかは、システムが自動でマッチングせず、人間が外から決める）」。

これは「あえてやらない」という判断です。こういう"不在"を従来のテストで確かめるのは困難ですが、AIに照合させることはできます。 「コードのなかに本当にスキルの項目が無いか」「割当を自動で算出してしまう経路が無いか」を、AIがコードベースを読んで確認するのです（"無いこと"を確かめるので負の照合と呼んでいます）。

ただし、ここはE2Eのとき以上に慎重であるべきです。「あることの確認」は一つ見つければ済みますが、「無いことの確認」はコードベース全体を見て初めて言える――AIが同義の実装（skillをproficiencyなどと書く等）を見落とせば、見つけられず「無い（ALIGNED）」と誤判定しかねません。「無いことの確認」は本質的に難しいのです。しかも、E2Eテストと違って実行による機械的な歯止めがありません（走らせてグリーン/レッド、とはいかない）。ですから、これはあくまで"ある程度"の信頼です。

整理すると、こうなります。

• 設計判断そのものが正しいか（Yes / No） ――これは人間が一つひとつレビューする。
• その判断が実際にコードベースへ落とし込まれているか ――自動テスト（fitness関数・型テスト・PBT）で打ち取れるものは打ち取る。難しいものはAIに照合させる。それでも信頼しきれない部分は、人間が目で見て確認する。

ちなみに、設計判断のなかには、そもそもテスト対象が定義上存在しないものもあります。たとえば「作業をどこまで細かく分解するか、その粒度は規則で縛らず人間の判断に委ねる」といった判断です。こういうものは自動テストにもAI照合にもなじまず、純粋に人間がレビューするしかありません。

どこまでを人間が所有し、どこまでをAIに所有させるか

最後に、まとめです。

ここまで、AI時代のボトルネックは人間のレビュー（最終判断）であること、そしてそれを解消するには 「人間がレビューすべき範囲を狭める」のが最もレバレッジが効く こと、をお話ししてきました。そして、それはボトルネックを消すのではなく、人間が立つ場所を、より小さく安定した面へ移すことだ、とも述べました。

そのためには、決定論的なプログラムで品質を機械的に裏打ちし、人間のレビュー対象を削っていくという考え方が軸になります。静的解析やリントもその一部ですが、いちばん大きな領域はやはり自動テストです。なかでも肝になるのは、人間の意図がきちんとテストに反映されること。だからこそ、それを ①E2Eテスト・②プロパティベーステスト・③設計判断の検証 という形に落とし込んでいくのが重要だ、という話でした（この3つは、人間がレビューすべき「意図の宿る面」で分けたものです。）。

では、これらを踏まえると開発の流れはどうなるのか。最後にその全体像を、Moira での実際のやり方を例にお話しします⁵。

Moira では、まず人間とAIが対話しながら、要件定義書にあたるものを「起点」として作り上げるところからすべてが始まります（「脇に置く」と言った要件定義も、流れのなかではここで登場します）。ただ、この起点となるドキュメントはかなり抽象的で、ブラッシュアップを重ねるうちに、人間が直接読んで理解するのが難しいものになっていきます。

そこで、これを人間がレビューしやすい3つの面に分割しています。

1. シナリオ（受け入れシナリオ集 ＝ 外的妥当性：作るべきものを作れているか）
2. プロパティの一覧（普遍条件の目録 ＝ 内的整合性：どんなときも破れない前提が守られているか）
3. 設計判断の一覧（設計判断の目録 ＝ 構造的健全性：保守性などの判断が筋を通しているか）

そして人間は、「このシナリオは私の意図どおりか」「このプロパティや設計判断はYesかNoか」を、自分の目で一つひとつレビューします。 ここが人間の所有する領域――先ほど言った「人間が立つ、小さく安定した面」です。

その先――これらを元にテストを書き起こす作業はAIが行い、そのテストの合否は決定論的に確認されていく。 だから、ここで品質はある程度まで機械的に裏打ちされる。もちろん、テストが通ることは欠陥の不在を証明するものではありません⁶。それでも、人間が一行ずつ実装を追う代わりに、意図そのものをレビューする場所へ立てる――これが私の考える、一つの理想的な開発の流れです。

繰り返しますが、これはあくまで一つの理想論であり、いま私が個人的に考えていることにすぎません。「いや、ここは違うのではないか」「ここはまだクリアできていないのではないか」――そうした議論のきっかけになれば幸いです。これを読んで何か考えたこと・ご意見・ご感想があれば、ぜひお寄せください。ありがとうございました。

---

脚注・典拠について (AIコメント)

本稿の事実主張のうち、Moira に関する具体例はすべて、その内部の確定文書（設計・仕様ドキュメント）に接地しています⁵。一般的な理論への参照は、広く確立された一次文献を挙げました。一般理論以外の3点――AIの推論コスト水準／AI時代のPBT／「レビューが律速する」という実証――は、追って Web 検索で裏取りし、出典を脚注に補った。結果として、推論コストの大幅な低下は権威ある統計で裏付けられた一方、「AIの方が人件費より安い」は現時点・多くのケースでの傾向にとどまり反対方向の予測（Gartner）もあるため断定は避けた（³）。AIによるPBT支援は研究の急増と先端企業の実運用までは事実として確認できたが、「主流化＝潮流」であるとは言い切れない（⁹）。「レビューが律速する」 は因果を分離した査読研究こそ乏しいものの、開発テレメトリで同じパターンが直接観察されており、本稿は〈理論的推論＋実データ〉として位置づけている（²）。

1. 制約理論（Theory of Constraints）。E. M. Goldratt & J. Cox, The Goal (North River Press, 1984)。「システムのスループットは制約（ボトルネック）が決める」「制約を解くと次の制約が現れる」（Five Focusing Steps）という考え方。 ↩ ↩²

2. 「AI 開発でレビュー（人間の最終品質判断）が律速になる」ことを RCT 等で因果的に分離した査読研究は、管見の限りまだ乏しい。一方、開発テレメトリではこのパターンが直接観察されている。Faros AI（1,255チーム・1万人超の実測, 2025）では、AI 高採用チームで完了タスク +21%・マージ PR +98% と生成側が増える一方、PR レビュー時間は +91% 増え、企業レベルのスループット・DORA 指標・品質には有意な改善が見られず、「下流のボトルネックが AI の増分を吸収する」と報告されている（"The AI Productivity Paradox," 2025）。Google の DORA レポートとも整合する（Accelerate State of DevOps 2024：AI 採用が約25%増えるとデリバリ安定性が約7.2%低下／State of AI-assisted Software Development 2025：AI は組織の強み・弱みを増幅し、PR を肥大化させてレビューを圧迫する）。なお、経験豊富な開発者を対象にした RCT では AI 利用でかえって作業時間が19%増えた例もあり（J. Becker, N. Rush, E. Barnes, D. Rein, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity," METR, arXiv:2507.09089, 2025）、「AI＝即高速化」という前提自体にも留保が要る。本稿の主張は、これら実データと、待ち行列／制約理論からの構造的推論に基づく位置づけとして読まれたい。 ↩ ↩²

3. 推論コストの低下。Stanford HAI, The 2025 AI Index Report, Chapter 1（2025）によれば、MMLU で GPT-3.5 相当（スコア64.8）を出すモデルの推論価格は、2022年11月の $20.00/百万トークン から 2024年10月の $0.07/百万トークン（Gemini-1.5-Flash-8B）へと、約18か月で「280倍以上」低下した。低下率はタスクや性能水準によって大きく異なる（性能を一定とすると年9〜900倍）：B. Cottier ほか（Epoch AI）, "LLM inference prices have fallen rapidly but unequally across tasks"（2025）。ただし「開発者の人件費よりAIの方が安い」は地域・利用量・モデル選択に強く依存し、直接比較した査読研究は確認できない。むしろ Gartner は、トークン消費の急増を背景に、2028年までにAIコーディングのコストが平均的な開発者の給与を上回りうると予測している（"Gartner Predicts AI Coding Costs Will Surpass Average Developer's Salary by 2028 as Token Consumption Surges," プレスリリース, 2026-06-24）。 ↩ ↩²

4. 待ち行列理論。J. D. C. Little, "A Proof for the Queuing Formula: L = λW," Operations Research (1961)。および処理窓口の稼働率が上限に近づくほど待ち時間が急増する性質（J. F. C. Kingman の近似, 1961）。 ↩

5. 本稿の Moira 具体例は、いずれも Moira 自身の内部設計文書に基づく（本記事執筆時点では未公開の個人プロジェクト）。具体的には、キャンセルのシナリオは受け入れシナリオ集に、プロパティ（達成率0〜100%＝PR-EVPCT-RANGE／記録順不変＝PM-ORDER-INV）はプロパティ目録に、設計判断（土台と計算の分離＝D-4／追記専用4イベント＝D-3／着手可否＝D-2／スキル非モデル化＝D-34）は設計判断カタログに、3面レビューの体系はプロジェクトのステアリング文書に、fitness関数は依存関係チェッカ（dependency-cruiser）による構成として、それぞれ管理している。 ↩ ↩² ↩³ ↩⁴ ↩⁵

6. E. W. Dijkstra, "Notes on Structured Programming" (1970) ほか。「テストはバグの存在を示すために使えるが、不在を示すためには決して使えない」。 ↩ ↩²

7. K. Claessen & J. Hughes, "QuickCheck: A Lightweight Tool for Random Testing of Haskell Programs," ICFP (2000)。ランダムテスト自体の着想はさらに古いが、shrinking を備えた PBT フレームワークとしての普及はここが起点。 ↩

8. PBT が実世界で普及しにくい理由。V. Vikram, C. Lemieux, J. Sunshine, R. Padhye, "Can Large Language Models Write Good Property-Based Tests?"（arXiv:2307.04346, 2023）の要旨は「PBT は研究分野では確立した技法だが、実世界のソフトウェアでは依然あまり使われていない。PBT を書く際の痛点は、多様なランダム入力生成器を実装することと、検証すべき意味のあるプロパティを考え出すことにある」と述べる（本文の『普遍条件の抽出』『テストデータ生成器の設計』に対応）。良いプロパティの見つけ方そのものを論じた文献として J. Hughes, "How to Specify It! A Guide to Writing Properties of Pure Functions"（TFP 2019）も参照。 ↩ ↩²

9. LLM にコードや docstring から「成り立つべきプロパティ（普遍条件）」を推論・生成させる研究は2023年以降に急増している（Vikram ほか2023〔上記 ⁸〕／M. Maaz, L. DeVoe, Z. Hatfield-Dodds, N. Carlini, "Agentic Property-Based Testing: Finding Bugs Across the Python Ecosystem," NeurIPS 2025 DL4C Workshop〔arXiv:2510.09907〕）。Anthropic は実際にこの方式の PBT エージェントを NumPy・SciPy・Pandas 等に走らせ、numpy.random.wald が負値を返すバグ等の修正を merge させた（Anthropic, "Finding bugs across the Python ecosystem with Claude and property-based testing," 2026-01-14。同社は「LLM は関数名・docstring・呼ばれ方などの文脈から、成り立つべきプロパティの特定が得意だ」と述べる）。 ↩ ↩²