時代が求める「説明可能なAI」-ブラックボックスを照らすXAIとは？
リプリパ編集部
リープリーパー
AI時代になぜシステム開発は失敗する？人間にしか問えない課題とは
kotobato
AIがコードを書く時代。ローコード・ノーコード開発も加速していますが、それでもITプロジェクトの失敗率は改善していません。なぜか？ボトルネックは「作ること」ではなく、「何を作るか？」に移っているからです。答えを出すのが速いAIも、問いを立てることはできません。
価値判断と説明責任は、プロジェクトオーナーであれ、エンジニアであれ、立場を問わず人間に残された仕事です。AIが何を変え、何を変えていないかを整理し、それぞれの立場からできることを考えます。
Contents
AIはコードを書けるが、何を作るかは決められない
一般に、DXに積極的な企業は、AIの導入にも前向きです。GitHub CopilotやClaude Code、Cursorといったツールは、エンジニアの生産性を劇的に押し上げ、かつては数週間か掛かっていた実装が数日で完成するケースも珍しくなくなりました。ローコード・ノーコードプラットフォームのさらなる普及と、複数ツールを組み合わせるマルチローコード戦略の浸透も重なり、「コードを書くこと」自体のハードルは今や劇的に下がっています。
しかし、以下のレポートによれば、DXに取り組んでいる企業は6割超ありますが、定着して継続的に実践・改善している企業は2割弱。また、業務コストの改善につながっている例が52.7％あるのに対して、収益の向上は29.8％に留まっています。
▼出典：
また、海外の事例を見ても、次の記事ではDXの70％が失敗すると指摘されています。
▼出典：
溯れば、MITが2025年に発表したレポートでは、エンタープライズにおける生成AIパイロットプロジェクトで、本番にまで行きつくのはわずか5％、残り95％は失敗（スケールしない）するという、衝撃的な数字が示されていました。
▼出典：The GenAI Divide STATE OF AI IN BUSINESS 2025
https://mlq.ai/media/quarterly_decks/v0.1_State_of_AI_in_Business_2025_Report.pdf
実装コストはある程度下がっても、プロジェクト全体の成否はあまり改善していない。この現実は、問題のボトルネックが「作ること」ではなく、別の場所にあることを示唆しています。そのボトルネックとは、そもそも「何を作るか？」という問いです。
最大の難問は、技術ではなく「意図の言語化」
システム開発が失敗するとき、その多くは「技術的な問題」ではありません。プロジェクトの上流で起きる、意図と認識のズレが根本にあります。
よく起きるパターンを整理すると、次のようなものです。ステークホルダーが「こんな感じで」と曖昧に伝えたイメージと、開発チームが解釈した仕様が、最初から噛み合っていない。あるいは、業務部門が「現在の業務をシステム化してほしい」と依頼したところ、それをそのまま実装した結果、業務の非効率さごとシステムに組み込まれてしまった。
よく引用される言葉に、『もし顧客に何が欲しいか尋ねたら、彼らは『もっと速い馬』と言っただろう』というものがあります（ヘンリー・フォード自身が発言したというのは誤解）。人は目の前の課題を「現在の手段の延長線上」で解決しようとしがちです。本当に解決すべき問題は何か？その問いを立てられなければ、どれだけ優れた技術があっても課題は解決されません。
ここで一つ、大切な視点を確認しておきます。要求定義・要件定義という呼び分けには、実はさほどこだわる必要はありません。これは、リープリーパーが以前の記事で解説した通りです。
その理由は、形式的なドキュメントの整備や、フェーズの細分化にこだわることが本質ではないから。重要なのは、呼び方が何であれ、「誰の、どんな問題を、なぜ解決するのか？」を関係者が共に問い直し、言語化して合意するプロセスそのものです。
AIが実装を高速化している今、このプロセスの重要性はむしろ増しています。
AIが変えたこと・変えていないこと
AIとローコード・ノーコードの組み合わせは、ソフトウェア開発の構造を根本から変えつつあります。ただし、変化のすべてが「良い方向」とは限りません。一旦、変化を整理してみましょう。
劇的に変え続けていること
AIによって、ローコード・ノーコードの普及がさらに加速しています。コーディング速度は劇的にアップし、非エンジニアでもソフトウェアを開発できるチャンスが拡がっています。特定のツールに依存するのではなく、用途に応じて複数のプラットフォームを組み合わせるマルチローコード戦略も広まっています。
エンジニアの役割も変わっています。コーディングから、テスト・レビュー・監修へのシフトが加速していて、AIが生成したコードを評価・統合する能力がより重要になっています。
経営層のコスト意識にも変化が起きています。ジュニアエンジニアを採用・育成するコストと、AIコーディングツールのサブスクリプション費用を比較検討する判断が、大企業でも現実の議題になっています。残酷な大量解雇や雇い控えのニュースを目にするたび、エンジニアやホワイトカラーが不安になるのも当然です。
変えていないこと（または、むしろ問題が加速）
2025年にバズワードとなったバイブコーディングは、こうした変化の象徴です。AIに「なんとなくこんな感じで」と伝えるだけでコードが生成される手軽さは、個人利用や試作段階では選択肢になりえます。
しかし、組織で運用・保守し続けるシステムへの安易な適用は、リスクが大きいことが知られるようになりました。誰が許可したのか分からない「野良AI」や、なぜ動くのかがわからない「野良コード」は、RPAやExcelマクロが長年抱えてきたリスクと本質的に同じ、技術的負債の温床です。
AIが普及しても変わっていない本質が、二つあります。
一つは、ビジネスを深く理解することの不可欠さです。どれほど実装が自動化されても、「この業務プロセスのどこに問題があるか？」「このシステムがどんなビジネス価値を生むか？」は、業務を知る人間にしか判断できません。
もう一つは、技術的なキャッチアップの継続です。AIが進化するほど、それを適切に使いこなし、評価し、監修する技術力が求められます。道具が変わっても、それを使いこなす専門性の重要性は変わりません。
そして最も重要な不変の事実とは、AIは「何を作るか？」を決めない・決められないという点です。
人間に残された領域は、価値判断と説明責任
確かに、AIは高品質なコードを爆速で書けます。設計の選択肢を提示することも、ドキュメントを生成することも、バグを発見することも得意。では、「このシステムを作るべきか？」という判断もAIにできるかといえば、答えは現時点では明確にノー。
ビジネス価値の優先順位付けは、組織の戦略・文化・制約を理解した上での判断です。どの機能を先に作るか？何を捨てるか？どのくらいのリスクを許容するか？これらは技術的な問いではなく、ビジネス上の意思決定です。そしてその判断には、説明責任が伴います。「なぜこの要件を優先したのか？」「誰が承認したのか？」を問われたとき、AIは答えられません。答えるべきは、人間です。
「実現ハードルの低下」と「価値判断の重要性増大」は、同時並行で起きています。これは矛盾ではなく、セットとして扱われるべきこと。誰でも作れる時代だからこそ、「作る価値があるものを見極める力」が差別化の源泉になります。これは、AIには代替できない、人間に残された中核的な仕事です。
ビジネスを理解する人間が、システムの成否を握る
この問題の構造が見えてくると、海外で起きている潮流の変化が腑に落ちます。
プロダクトマネージメントの世界では、「Output（機能の量）よりOutcome（成果）を追え」という考え方がすでに主流となっています。「Jobs to be Done（片付けるべき用事）」フレームワークは、ユーザーがプロダクトを使う本当の目的を問い直す手法として、多くの企業で採用されています。デザインシンキングも、「共感→問題定義→アイデア創出」という順序で、解決策を考える前に問いを立てることを重視します。上流の問いの質がプロジェクト全体を左右します。
こうした潮流を支える職種として、改めて注目されているのが「ビジネスアーキテクト（BA）」です。ビジネスプロセスとITシステムの両面を理解し、組織の課題を構造的に捉え、解決策を設計するこの役割は、AI時代にさらに価値を増しています。BlueMemeでも、多くのビジネスアーキテクトが今日も現場で活躍しています。
日本特有の構造的な問題
ここで、改めて日本固有の課題を直視しておく必要があります。
例えば、日本の内製化率・傾向をアメリカ・ドイツと比較したレポートが顕著です。アメリカは、コア領域は自社開発が主流で、DXに本気の企業ほど内製化が高い傾向にあります。事業のコア機能やデジタルサービスを自分たちで作る文化が強いといえます。また、ドイツは、内製・外注・パッケージをバランスよく使い分けつつ、内製化を重視しています。
一方、日本は、コア領域でも外部ベンダーに依存する傾向があります。DXに取り組む企業ですら、「内製でアジリティーを高める」発想が浸透していません。人材不足が最大のネックになっているため、内製化の必要性は、認識しつつ実行に移し切れていない構図です。
▼出典：
この違いが意味することは一つ。日本企業の多くは、自社のシステムを「自分ごと」として理解していない、ということです。外部のSIerに聞かなければ自社の詳細がわからないという本末転倒は、残念ながらよくある話。
AIがどれほど優秀になっても、発注側に「何を解決したいのか？」を言語化できる人がいなければ、状況は変わりません。内製化率を上げるとは、単にエンジニアを社内に置くことではありません。ビジネスを理解した上でITの問いを立てられる人材を、組織の中に育てることです。
あなたの立場で、今すぐできること
人は、組織に属しているかどうかに関わらず、理論だけでは動けませんし、何をすべきかは立場によっても違います。共通していえることが一つあるとしたら、それは「見えない・知らない・分からない」ことが、大体の不安の元凶だということ。慌てず、焦らず、諦めず。まず変化を正確に見ることから始めてみませんか？
意思決定・承認する立場の人
例：プロジェクトオーナー、DX推進管理職、経営層
あなたの最も重要な仕事は、「なぜ作るか？」を問える場をプロジェクト開始前に意図的に設けることです。要件への承認は「機能リストへのサイン」ではなく、「何を解決するかへの合意」です。AIが出した提案に対して「なぜ？」と問い返せるか。説明責任を持つ者として、その問い返しを習慣にしてみましょう。
要件を整理・橋渡しする立場の人
例：PM、BA、業務部門のキーパーソン
あなたには、ビジネスとITの両言語を持つ責任があります。「現状の業務」と「理想の状態」を混在させないワークショップの設計、ユーザーストーリーによる意図の構造化、MoSCoW法（Must（必須）、Should（すべき）、Could（できれば）、Won’t（不要）の4つで優先順位を付ける手法）による優先順位の明確化など、これらは道具です。目的は、「誰の、どんな問題を、なぜ解決するのか？」を関係者全員が共有した状態を作ること。AI時代に最も価値が上がるのは、この橋渡しができる人材です。
実装に近い立場の人
例：エンジニア全般、キャリアの入口にいる人
コーディング単体のスキルが相対的に価値を下げていく流れに対して、否定や抵抗しても意味がなく、起きていることはすべて現実。ただし、「実装を知っている人間がビジネスを理解しようとする」ことと、「ビジネスしか知らない人間がAIに発注する」ことは、まったく違います。技術的なバックグラウンドは、要件を正しく問い直す力の土台になります。
あなたが今すぐできることは、一つ。それは、今のプロジェクトで、「なぜこの機能が必要なのか？」を一度でも問い返してみることです。その問いを習慣にすること自体が、AIで劇的に変わり続ける、BANI（脆弱性があり、不安な、非線形の、理解不能な）な時代を生き抜くキャリアの起点になります。
変化のスピードは加速度的に速まっていて、AIというブラックボックスに丸投げで「知らない」ままでいることのコストは、今後も上がり続けます。慌てず、焦らず、しかし、常に変化をウォッチし続けること。それがすべての立場に共通する、今日からできる最初の一歩です。
素早く答えを出すのがAI＋問いを立てるのは人間
AIがコードを書く時代でも、プロジェクトが失敗する理由は変わっていません。「何を作るか？」が曖昧なまま、「作ること」が始まるからです。
ただし、その問題の重さや速度は変わりました。実装が速くなるほど、間違いが早く大きく育ちます。AIが実装を代替するほど、価値判断と説明責任は人間の仕事として際立ちます。日本企業の多くは、未だに「作る」フェーズを外部に委ねています。その構造を変えない限り、どれほど優れたAIツールが登場しても、根本は変わりません。
ビジネスアーキテクトという肩書きの有無は問いません。「業務を理解し、技術と事業をつなぐ問いを立てられる人」の存在が、AIを活かすか殺すかを決めます。速く作れる時代だからこそ、「何を作るか」に投資することが、最も確実なDXの近道です。
次回は、意図が定まった後、実行フェーズはどう変わるのか。「バイブコーディング」の次の段階、「エージェントエンジニアリング」の世界へと議論を進めます。
曖昧な意図をいくら加速しても、技術的負債が増えてしまうだけ。AIやローコードでは、「最初の問い」の質がプロジェクト全体の成否を左右します。
BlueMemeの強みは、「問いを立てる」専門支援としての実績です。企業活動をビジネス層・アプリケーション層・テクノロジー層の3階層に分割してモデル化します。御社も、自社に必要な技術の導入を「自ら判断できる」柔軟性を実現しませんか？ぜひ一度、私たちにご相談ください。
ABOUT ME
企画制作や広告クリエイティブ畑をずっと彷徨ってきました。狙って作るという点ではライティングもデザインの一つだし、オンラインはリアルの別レイヤーで、効率化は愛すべき無駄を作り出すため。各種ジェネレーティブAIと戯れる日々です。
kotobatoの記事一覧
kotobatoの記事一覧
