2026年8月19日、Polaris.AI株式会社はオンラインセミナー「AI開発の要件定義は、なぜシステム開発と同じやり方では失敗するのか」を代表取締役CEOである徳永による登壇で開催しました。AI開発の要件定義には、まだ確立された方法論がありません。従来のシステム開発の進め方をそのまま当てはめると、自社開発かSaaS契約かの切り分け、精度要件のすり合わせ、AIに任せる部分とロジックで処理する部分の使い分けなど、さまざまなところで判断がずれていきます。本セミナーでは、東京大学 松尾研究室発のスタートアップとして数多くのAI開発に取り組むなかで見えてきた、AI特有の検討論点とその扱い方をお話ししました。本レポートでは、当日の講演内容を、投影資料を交えながらお伝えします。講演の結論：3つの見極めが、成否を分ける徳永は冒頭で、この日の結論を先に提示しました。AI開発の失敗のほとんどは、「解く価値・解ける形・動く場所」——要件定義における、この3つの見極めの甘さで説明できる。そして、これらを最初から押さえておけば、プロジェクトを止めうる要因の多くは事前に取り除ける、というものです。そして、これらを最初から押さえておけば、プロジェクトを止めうる要因の多くは事前に取り除けると述べました。AI開発の要件定義——成否を分ける3つのこだわり（講演資料 P.19）課題選定にこだわる ——「解くに値するか」を疑うタスク設計にこだわる ——「解ける形」に翻訳する運用への組み込みにこだわる ——「現場で動く形」まで詰める以下、順にご紹介します。1. なぜ、AI開発の要件定義は難しいのかAIは確率的である、という前提従来のシステム開発の要件定義は、「正しい挙動そのものを決める」ことを目指します。機能・画面・帳票といった仕様は正解を書き切ることができ、品質の根拠は仕様書にあり、開発前に凍結できます。一方でAIは、人間が書いたルールではなく、データから調整されたパラメータによって出力を導き出すため、挙動は確率的になります。そのため要件定義は、「正解を書けない前提で、合格の判定方法を先に決める」ことを目指すものへと変わります。書けるのは入力・出力・評価指標までで、品質の根拠は評価データと合格ラインの合意に移り、内容はデータを見ながら段階的に確定していきます。従来のシステム開発と、AI開発の根本的な違い（講演資料 P.14）この違いを踏まえずに従来の型を当てはめると、「何をもって完成とするのか」が最後まで定まらないまま開発が進んでしまいます。課題が一言変われば、解くべき技術は丸ごと変わるもうひとつの難しさが、AIプロジェクトの個別性です。生成AIの進化により、対応できる範囲は確かに広がりました。しかし、ミッションクリティカルな領域で精度を追求する場合には、課題ごとに異なる技術構成が必要になります。徳永は、Polaris.AIが実際に取り組んできた案件のイメージを挙げながら、現場の課題と技術の組み合わせの対応関係を示しました。課題が変われば、解くべき技術構成も変わる（講演資料 P.16）たとえば「何万ページもある船のマニュアルを、調べるだけで半日かかる」という課題には、OCR・チャンキングからハイブリッド検索、リランカー、LLMという構成が向きます。一方、「工作機械が突然止まると、ラインごと止まる。壊れる前に知りたい」という課題では、信号処理や変化点検知、波形クラスタリングといった、LLMとはまったく異なる技術が中心になります。経験を積んだ人であれば、左側の課題を見た瞬間に右側の技術構成が思い浮かぶ。逆に経験がなければ、この右側が出てこない。だからこそ、どこに気をつければ右側にたどり着けるのかを共有したい——それが、徳永がこの日のテーマに据えた問題意識でした。失敗の多くは、最初の2フェーズで仕込まれるAI開発は、課題選定・タスク設計・データ収集・モデル学習・デプロイ・改善という6つのプロセスからなります。このうち最初の2フェーズが、いわゆる要件定義にあたります。AI開発の全体像と、要件定義の位置づけ（講演資料 P.17）上流の判断を誤ると、下流に進むにつれて手戻りのコストは大きく膨らみます。徳永は、これは一般的なプロジェクトにも共通する構造だとしたうえで、AI開発では非機能要件をひとつ見落としただけで実装そのものが成り立たなくなる場合がある点に注意を促しました。2. こだわり1｜課題選定：「解くに値するか」を疑うカスタムAI開発は、最後の選択肢最初のこだわりは、課題選定です。徳永が繰り返し強調したのは、カスタムAI開発は課題解決の手段のなかでもコストがかかる選択肢である、という点でした。「AI開発」に踏み切る前の、問いの順序（講演資料 P.20）問うべき順序は、コストの低いものからです。まず、解くべき課題が明確か。次に、オペレーション改善で解決できないか。既存のSaaSやiPaaSで代替できないか。ノーコードツールで開発できないか。そのすべてを潰したうえで、「それでもAIを開発する価値はあるか」を問う。この順序を踏まずに開発に着手すると、後から「SaaSのほうが良かった」「汎用LLMへのプロンプトで十分だった」という手戻りが生じます。開発したあとで「こちらのSaaSのほうが良かった」となれば、発注する側にとっても開発する側にとっても良い結果にはならない。中長期でAI活用を進めるのであれば、最初に考えておくべき点である、と徳永は述べました。「嬉しさ」を、金額まで分解する課題選定のもうひとつの論点が、投資対効果です。「〜できたら嬉しい」で始まったプロジェクトは、判断の基準を持てないまま進みがちです。徳永は、「誰の・何が・どれだけ変わって・年間いくらか」まで分解することを勧めました。異常予知を題材にした分解の例（講演資料 P.21｜数値は説明のための試算例です）工作機械の異常予知を題材にした試算例では、現状の稼働率と突発停止の回数、1回あたりの復旧時間とライン停止損失を積み上げることで、年間損失額を可視化しています。そのうえで、稼働率を99.5%から99.8%へ引き上げた場合、99.9%へ引き上げた場合と、改善レベルごとに投資回収の成立性を並べています。この分解によって、狙うべきラインが決まり、PoC（実現可能性を検証する試行）で確かめるべきことが決まります。同時に、「書いてはいけない数字」も見えてきます。技術的に保証できない水準を要件として書き込んでしまうと、プロジェクトはそこで詰まってしまうためです。3. こだわり2｜タスク設計：「解ける形」に翻訳する入力Xと出力Yを定義し、「原理的に解けるか」を検証する課題が定まったら、次は業務の言葉をAIが解けるタスクへ翻訳します。その本体が、入力Xと出力Yの定義です。ここで徳永が紹介したのが、「ベテラン10人テスト」という検証方法でした。原理的に解けるかを判定する「ベテラン10人テスト」（講演資料 P.24）その業務のベテラン10人に、定義した入力Xだけを渡して、出力Yを出してもらいます。10人が同じ答えを出すなら、正解が一意に定義でき、原理的に解けるタスクです。5人以上が揃うなら、揃わない部分の判断基準を明文化することで前進できます。答えがばらばらであれば、人間に正解を定義できないものはAIにも学べないため、タスクの切り方そのものを変える必要があります。業務フロー図に記載された3つの入力から、ベテランは本当にその出力を導けるのか。実際に問いかけてみると、工程の情報や他部署のリソース状況、過去の失敗経験など、フロー図に現れない知識を前提にしているケースがほとんどだと徳永は述べました。AIに人間と比べて欠けている情報があれば、原理的に人間と同じ精度には届きません。そこで、暗黙知をどこまで形式知化するかという論点に進むか、あるいは「ベテランと同じ精度でなくても業務は回る」という水準で合意するかを、開発前に見極めることになります。データが「ある」ことと「使える」ことは、別の話入力を定義できても、そのデータが実際に用意できるとは限りません。データ化されていない、整備されていない、アノテーションがない、社外に持ち出せない——揃ってから始まるプロジェクトはほとんどない、というのが実感だと徳永は語りました。データが揃わない前提での、対応策の例（講演資料 P.25）対応の方向はふたつあります。ひとつは、問いそのものを簡単にすること。揃っているデータで解ける問いへ課題を再定義し、Yes/Noで答えられる形に変える、細かく分類せずざっくり分ける、まずはルールベースのみで作ってみる、といった選択肢があります。もうひとつは、足りないデータを外から補うこと。公開データセットや学習済みモデル、合成データを活用します。徳永は補足として、図面やCAD、官公庁の帳票のようなデータは世の中にあまり存在しないと思われがちだが、テンプレート的なものであれば研究者がデータセットとして公開している場合が多く、8割程度の検証を公開データで進められるケースもあると述べました。指標が、ビジネス価値とずれていないか3つ目の論点が、評価指標の設計です。指標の選び方次第で、同じAIが「優秀」にも「無価値」にも見えてしまいます。業務のリスク構造が、重視すべき指標を決める（講演資料 P.28）1,000件中10件の異常を見つけたい検査で、すべてを「異常なし」と答えるAIをつくれば、正解率は99%になります。数字としては良く見えても、業務上の価値は生まれていません。判断の軸になるのは、業務のリスク構造です。見逃しのコストが高い業務では再現率（Recall）を最重視し、適合率（Precision）も一定以上を確保する。誤検知による人手確認のコストが高い業務では、適合率を最重視する。ビジネスKPIに直結する損失から主軸となる指標を決め、複数の指標で総合的に評価する必要がある、というのが講演で示された考え方でした。あわせて、精度にはコストが伴う点にも言及がありました。80%を90%にするのと、90%を99%にするのとでは難易度が桁違いに異なります。その1%が本当に業務に必要なのかを、要件を確定する前に問うことが求められます。4. こだわり3｜運用への組み込み：「現場で動く形」まで詰めるそのAIが現場で動いている朝を、具体的に描けるか3つ目のこだわりは、運用への組み込みです。PoCで精度が出ることと、現場で毎日動くことの間には、大きな距離があります。逆算ありのPoCと、逆算なしのPoC（講演資料 P.31）入力Xはどこから来て、出力Yは誰のどの画面に届くのか。この組み込み先を最初に想像しておくと、プロジェクトを止めるボトルネックが先に見えてきます。徳永は、既存の基幹システムを日常的に使っている現場において、新しいアプリケーションを追加で開くオペレーションは定着しにくいと指摘し、SFAやCADなど既存ツールへのプラグインとして組み込む選択肢も含めて、初期段階から検討する必要があると述べました。そのほか、社内の監査ルール上どこまでのデータをAIに渡せるのか、既存システムからAPIやMCP（AIと外部システムを接続する規格）を経由してデータを取り出せるのか、といった論点も、要件として先に洗い出しておくべき対象です。非機能要件が、機能の作り方を決めるLLM APIを使えば、「動くもの」は短期間でつくれます。しかし、現場の制約がひとつ加わるたびに、選べる技術は変わっていきます。制約が、使えるAIそのものを変える（講演資料 P.33）機密データを社外に出せないのであれば、オンプレミスで動くモデルへ。出力の再現性が必要であれば、決定的なモデルやルールベースへ。画像のどこを、どの確信度で判断したのかという座標とスコアが必要であれば、従来の物体検出モデルへ。応答が0.1秒以内でなければならないなら、軽量な専用モデルへ。API費用に上限があるなら、小型モデルの自社運用へ。こうした制約を通過して、最終的にビジネス要件を満たすアーキテクチャが残ります。徳永は、この検討結果はタスク設計に跳ね返ってくるため、最後に確認する項目ではなく最初から考えるべき論点だと締めくくりました。おわりに要件定義に確立された型がない以上、判断のよりどころになるのは、実務のなかで積み上がった論点の整理です。本セミナーでお伝えした「解く価値・解ける形・動く場所」という3つの見極めが、これからAIプロジェクトに取り組まれる方の検討の一助となれば幸いです。Polaris.AIでは、AI開発の構想段階からのご相談を承っています。「この課題はAIで解くべきなのか」「どこまでの精度が現実的なのか」といった、要件が固まる前の段階でのご相談も歓迎しております。▶︎Polaris.AIへのお問い合わせはこちら