「AIはしょぼい」で終わらせるのは、少しもったいない。成果を左右する6つの設計要素

「AIって、思ったより使えないよね」

「平気で嘘をつくし、出してくるコードも雑だ」

仕事で生成AIを使ったことがある人なら、一度くらいはこう感じたことがあるのではないでしょうか。

私にも、AIが存在しない機能を当然のように説明したり、頼んでいない箇所まで勝手に変更したりして、「どうしてそうなるのか」と思った経験があります。

実際、現在のAIには明確な限界があります。

長い作業では、最初に伝えた条件を取りこぼす。局所的には正しい修正をしながら、別の機能を壊す。分からないと止まる代わりに、もっともらしい答えを作ってしまう。

ですから、「AIの成果が悪いのは、全部使い手の責任だ」と言うつもりはありません。

ただ、その一方で、失敗の原因を詳しく見ていくと、本当にモデルだけが悪いのだろうかと思う場面も少なくありません。

目的が曖昧なまま「いい感じに作って」と頼む。必要な資料を渡していない。設計、実装、テストを一度に任せる。正しいか確認する仕組みもない。それでも一度の生成で完成品が出てくると期待する。

この状態で「AIはしょぼい」と結論づけてしまうのも、少しもったいないと思います。

私の結論は、次のとおりです。

AIの成果は、モデル単体から生まれるものではありません。

人間が何を頼み、どの情報を渡し、どのように作業させ、何を使って確認するのか。その仕事の仕組み全体から生まれます。

AIの成果は、プロンプトだけでは決まらない

生成AIの使い方というと、すぐに「よいプロンプトを書きましょう」という話になりがちです。

もちろん、指示の書き方は重要です。

しかし、実務で安定した成果を出すには、プロンプトよりも広い範囲を考えなければいけません。

私は、AIの成果を左右する要素を、次の6つに分けています。

1. モデル能力

2. 要件定義

3. コンテキスト

4. ハーネス

5. 評価・検証

6. 実行環境と権限

これは厳密な数式ではありません。

AIがうまく働かなかったときに、「どこを直せばよいのか」を探すための診断フレームです。

一つずつ見ていきましょう。

1．そもそも、モデルには得意・不得意がある

最初に確認しておきたいのは、モデルの違いは確実に存在するということです。

同じ指示、同じ資料、同じテストを用意しても、使うモデルや製品によって結果は変わります。

短い文章の要約が得意なモデルもあれば、複数ファイルを編集する作業に強いモデルもあります。ツールを正確に使えるか、長い作業で方針を維持できるか、失敗後に立て直せるかにも差があります。

したがって、

とは言えません。

むしろ、要件やテストをきちんとそろえるほど、モデルごとの違いは見えやすくなります。

曖昧な依頼では、偶然うまくいったのか、モデルが本当に優れていたのか分かりません。

同じ条件で繰り返し試して初めて、そのモデルの得意な仕事と苦手な仕事が見えてきます。

2．要件が曖昧なら、AIは空白を勝手に埋める

次に大きいのが、要件の問題です。

例えば、AIへ次のように依頼したとします。

人間同士でも、これだけでは判断に困ります。

誰が使う画面なのか。何をもって「使いやすい」とするのか。見た目を変えてよいのか。機能を追加してよいのか。既存ユーザーの操作方法を変えてよいのか。

必要な条件が分からなければ、AIは空白を推測で埋めます。

そして、その推測が利用者の期待と違ったときに、「勝手なことをした」「AIは分かっていない」という評価になります。

もちろん、AI側が不足情報を質問すべき場面もあります。

しかし、現状の製品は、いつも適切な質問をしてくれるとは限りません。分からない部分があっても、頼まれた成果物を完成させようとして、そのまま進んでしまうことがあります。

だからこそ、依頼するときには、少なくとも次を整理した方がよいでしょう。

• 何を作るのか

• 誰が使うのか

• 何を変更してよいのか

• 何を変更してはいけないのか

• どの状態になれば完成なのか

• 不明な場合に進むのか、止まって確認するのか

ここで大切なのは、長いプロンプトを書くことではありません。

AIが判断してよい範囲と、人間へ確認すべき範囲を分けることです。

3．必要な情報を渡さず、正確さだけを求めていないか

AIは、知らない事情を察してくれる超能力者ではありません。

仕事に必要な情報へアクセスできなければ、不足部分は一般論や推測で補うしかありません。

ソフトウェア開発なら、次のような情報が必要になります。

• 現在のコード

• システム全体の構成

• 使用しているバージョン

• 過去に採用・却下した設計

• 守るべきセキュリティ要件

• 変更してはいけない箇所

• 既存のテストやコーディング規約

記事制作なら、必要な情報はまた変わります。

• 誰に向けた記事なのか

• 著者はどの立場から書くのか

• 何を中心的に伝えたいのか

• どの情報が確認済みなのか

• どの体験が本人のものなのか

• 参考記事と何を差別化するのか

こうした情報を与えずに、「こちらの意図を理解して正確に作って」と求めるのは、人間の担当者に資料を渡さず、「間違えずに仕上げてください」と言うのに近いものがあります。

AIへ与える情報は、多ければ多いほどよいわけではありません。

関係のない資料を大量に渡せば、かえって重要な条件が埋もれることもあります。

必要なのは、量ではなく、仕事の判断に必要な情報を選び、分かりやすい順序で渡すことです。

4．一度の指示で、全部やらせようとしていないか

ここから、少し技術的な言葉を使います。

AIにどの順序で作業させ、どのツールを使わせ、どこで止め、いつ人間が確認するか。その実行の枠組みを「ハーネス」と呼ぶことがあります。

名前は難しく聞こえますが、考え方自体はシンプルです。

例えば、大きなシステム改修を次のように依頼したとします。

一見すると効率的です。

しかし、途中で設計を誤っていても、人間が気づかないまま実装が進みます。テスト自体が不十分なら、問題があるのに「成功」と判断するかもしれません。

そこで、作業を次のように分けます。

1. 既存の資料とコードを読む

2. 不明点を整理する

3. 変更方針を作る

4. 人間が変更範囲を確認する

5. 実装する

6. テストを実行する

7. 差分をレビューする

8. 問題があれば修正へ戻る

9. 本番操作の前に承認を求める

このようにすると、問題を早い段階で発見できます。

設計が間違っているのに最後まで作り切ってしまうより、方針の段階で止めた方が、手戻りは小さくなります。

AIに長く自律的に動いてもらうこと自体が、よい設計なのではありません。

必要な場所で止まり、確認し、失敗したら適切な工程まで戻れることの方が重要です。

5．一番重要なのは、間違いが分かること

私は、AI活用において最も重要なのは、上手な指示を書くことよりも、出てきた成果が正しいか判断できることだと考えています。

AIを一度も間違えさせないプロンプトを探しても、完全なものは見つかりません。

それよりも、

方が現実的です。

Google DeepMindのAlphaEvolveは、AIにアルゴリズム案を作らせるだけではありません。生成した候補を自動評価器で採点し、有望な案を選びながら改善を繰り返します。成果を生み出しているのは、生成モデル単体というより、生成と評価を組み合わせた仕組みです。

Anthropicも、AIエージェントの開発では、評価の仕組みによって問題や挙動の変化を本番前に発見することが重要だと説明しています。問題が利用者へ届いてから対応するのではなく、失敗を評価項目へ変えて再発を検出する考え方です。

評価方法は、仕事によって変わります。

コードなら、テスト、型検査、Lint、静的解析があります。

調査なら、一次情報、日付、数字、引用元を確認します。

数値分析なら、再計算し、単位、合計、母数が合っているかを見ます。

記事なら、主張と出典が対応しているか、事実と意見が混ざっていないかを確認します。

業務自動化なら、まずdry-runで実行結果を確認し、承認後に本番へ進めます。

ここで発想を少し変える必要があります。

AIを絶対に間違えさせないことを目指すのではありません。

間違えても、そのまま顧客、社外、本番環境へ届かないようにするのです。

6．便利だからといって、広い権限を与えてはいけない

AIが文章案を作るだけなら、誤りの多くは品質問題で済みます。

しかし、GitHub、メール、顧客データ、クラウド、本番システムへ接続すると、話は変わります。

間違った文章を書くことと、間違った設定を本番環境へ反映することでは、影響の大きさがまったく違います。

OWASPは、エージェント型AIの主要なリスクとして、エージェントの目標が外部から書き換えられること、ツールが不正利用されること、IDや権限が悪用されること、予期しないコードが実行されることなどを挙げています。

だから、AIが賢くなったからといって、すぐに広い権限を渡すべきではありません。

むしろ、賢いAIであっても、次のような制御が必要です。

• 必要最小限の権限だけを与える

• 読み取りと書き込みを分ける

• 本番とは分離された環境で試す

• 最初はdry-runで動かす

• 変更差分を人間が確認する

• 送信、公開、削除、本番反映には承認を求める

• 認証情報をAIから隔離する

• 何を実行したかログへ残す

• 問題が起きたら元へ戻せるようにする

自律性が高いことと、安全であることは別です。

「どこまで自動化できるか」だけでなく、「どこから先は人間が責任を持つか」を決める必要があります。

「AIが嘘をつく」の中身を、もう少し分けて考える

AIが存在しないAPIを紹介したり、架空の出典を示したりすることはあります。

利用者からすれば、「嘘をつかれた」と感じるのも無理はありません。

ただ、改善方法を考えるためには、その中身をもう少し細かく分けた方がよさそうです。

AIの誤りには、例えば次のような原因があります。

• 必要な情報がなく、空白を推測で補った

• 古い学習データを使った

• 公式資料を確認せず、記憶だけで答えた

• 最初に立てた誤った仮説を修正できなかった

• 「分かりません」と止まらず、続きを生成した

• 利用者が断定的な回答を求めた

• 正誤を確認する手段がなかった

こう考えると、「嘘をつかないでください」という指示だけでは不十分だと分かります。

実務では、次のような確認条件へ変換した方が効果的です。

• APIや仕様は公式資料で確認する

• 確認済み情報と推測を分ける

• 実在確認できない機能は使わない

• 使用するバージョンを特定する

• 不明な場合は進めず、確認を求める

• コードはコンパイルとテストを行う

• 調査結果には出典と確認日を残す

「幻覚しないAI」を期待するよりも、幻覚が成果物へ残らない仕事を作る。

私は、こちらの方が実務的だと思います。

それでも、モデル側の限界は確実に残る

ここまで読むと、「結局、ちゃんと設計すればAIは何でもできるのでは」と感じるかもしれません。

残念ながら、そこまで単純でもありません。

特に、長期間にわたる複雑な作業では、現在のAIはまだ苦戦します。

SWE-EVOという研究では、平均21ファイル、平均874件のテストにまたがる、長期的なソフトウェア変更をAIエージェントへ実行させました。

その結果、GPT-5とOpenHandsの組み合わせでも解決率は21％でした。同じ研究内で示された、単一Issueを中心とするSWE-Bench Verifiedの65％と比べても、大きな差があります。

これは一つのベンチマーク結果であり、すべての開発業務へそのまま一般化はできません。

それでも、短いバグ修正と、複数工程にまたがる長期的な変更は、別の難しさを持っていることが分かります。

長い作業では、AIに次の能力が必要です。

• 途中の判断を覚えておく

• ファイル間の関係を理解する

• 計画が間違っていたら修正する

• 既存機能を壊さない

• 過去の失敗を次へ引き継ぐ

• 必要な情報だけを残し、不要な情報を捨てる

• 自信がないときに止まる

要件、資料、テストを整えても、同じ失敗が繰り返されるのであれば、それは利用者だけの問題ではありません。

モデルやエージェント製品の能力限界として扱うべきです。

AIを使えば、必ず仕事が速くなるわけでもない

AIの話をするとき、もう一つ気をつけたいことがあります。

それは、「AIを使った」という事実と、「生産性が上がった」という結果を同じにしないことです。

METRが2025年に行った実験では、対象のオープンソースプロジェクトへ平均約5年間関わっていた熟練開発者16人が、AIを利用した場合、作業時間が平均19％長くなりました。

興味深いのは、参加者自身はAIによって速くなったと感じていたことです。主観的な手応えと、実際にかかった時間が一致していませんでした。

ただし、この結果から「AIは開発者を遅くする」と一般化することもできません。

METRが2026年に公開した追加調査では、以前より改善している可能性が示されました。一方で、AIを使いたい参加者が集まりやすいなどの選択バイアスがあり、正確な効果量はまだ不確実だと説明されています。

ここから分かるのは、AIが速いか遅いかではありません。

見るべきなのは、コードを書いている時間だけではありません。

• 指示を作る時間

• AIの提案を読む時間

• 修正を依頼する時間

• 人間が手直しする時間

• レビューとテストの時間

• 後から発生する再作業

• 不具合や保守の負担

• AIサービスの利用費用

まで含める必要があります。

生成速度が上がっていても、確認と修正に時間がかかっているなら、全体として速くなっているとは限りません。

一人がたくさん作れても、組織全体が速くなるとは限らない

この問題は、個人だけでなく組織でも起きます。

AIによって一人が大量のコードや文書を作れるようになると、成果が増えたように見えます。

しかし、レビューする人、承認する人、保守する人の処理能力が変わっていなければ、別の場所に仕事がたまります。

2025年のオープンソースプロジェクトを対象とした研究では、GitHub Copilot導入後、周辺的な開発者の生産量は増えた一方、コードの再作業も増えました。

また、コア開発者がレビューするコードは6.5％増え、コア開発者自身のコード生産性は19％低下したと報告されています。

これは観察研究です。AI導入だけが原因だと断定したり、すべての企業へ結果を当てはめたりすることはできません。

ただし、重要な示唆があります。

AIによって生成物だけが増えると、レビュー待ち、差し戻し、保守負担が増える可能性があります。

生成したコードの行数や、作った資料の枚数だけをKPIにするのは危険です。

見るべきなのは、その成果が安全に確認され、実際に利用者へ価値として届いたかどうかです。

熟練者は、AIへ丸投げしているわけではない

AIを使いこなしている人を見ると、何でもAIへ任せているように見えるかもしれません。

しかし、実際には逆です。

2025年に、熟練開発者13人の観察と99人への調査を行った研究では、経験豊富な開発者はAIエージェントを評価しながらも、設計や実装の主導権を自分たちで保持していました。専門知識を使い、AIの挙動を細かく制御していたのです。

熟練者は、単にプロンプトを上手に書いているのではありません。

• そもそもAIへ任せてよい仕事か

• 変更範囲が広がりすぎていないか

• 既存設計と矛盾していないか

• 不要な仕組みを増やしていないか

• テストが表面的な成功だけを見ていないか

• セキュリティ上の問題がないか

• 途中で止め、別の方法へ切り替えるべきか

を判断しています。

AIによって、コードや資料を作る作業の一部は、以前より多くの人に開かれました。

一方で、何を作るべきか、どこまで任せるべきか、結果を信用してよいかを判断する力は、むしろ重要になっています。

専門家が不要になるというより、専門家の役割が変わっているのだと思います。

手を動かしてすべてを作る人から、目的、制約、評価基準、例外処理を設計する人へ。

この変化は、これからさらに進むはずです。

初心者には便利だからこそ、「分かった気になる」危険がある

AIは、初心者にとって非常に便利です。

エラーの意味を説明してくれる。サンプルコードを作ってくれる。分からない用語を何度でも聞ける。

うまく使えば、学習のハードルを大きく下げてくれます。

ただ、成果物を作れたことと、その仕組みを理解できたことは同じではありません。

2026年に初心者プログラマー78人を対象として行われた研究では、AIを自由に使ったグループは課題を完成できた一方、その後にAIなしで行った保守課題では77％が失敗しました。

AIが生成したコードを取り込む前に、内容を自分の言葉で説明させる仕組みを設けたグループの失敗率は39％でした。研究者は、動く成果物を持っていても、修正に必要な理解を持っていない状態を「epistemic debt」、認識上の負債と表現しています。

もちろん、これは一つの実験であり、対象も初心者に限られています。

すべての学習者や利用方法へ一般化することはできません。

それでも、「作れたから理解できた」と思い込む危険は、私自身も非常に重要だと感じます。

初心者へAIを使わせないことが解決策ではありません。

AIを使いながら、次のような確認を取り入れるべきです。

• なぜこの実装にしたのか説明する

• 別の方法と比較する

• どのようなエラーが起きそうか予測する

• テストケースを自分で考える

• AIの出力から間違いを探す

• 一部分をAIなしで修正する

AIを答えの自動販売機として使うのではなく、理解を深めるための対話相手として使う。

教育では、この違いが大きいと思います。

「全部ユーザーが悪い」は、製品側の責任逃れにもなる

ここまで、利用者や組織が改善できることを多く挙げてきました。

しかし、「成果が悪いのは使い手のせいだ」と言い切ることには、別の危険があります。

製品側の問題まで、利用者へ押しつけられてしまうからです。

例えば、エージェント製品に次の問題があったとします。

• 要件が曖昧でも、そのまま進めてしまう

• 危険な変更を警告しない

• テストを実行しない

• 変更した理由を説明しない

• 長い作業で途中の状態を失う

• どの権限を使ったか分からない

• 失敗しているのに成功したように見せる

• 実行履歴を確認できない

これらをすべて「プロンプトが悪い」で済ませるのは不適切です。

よい製品であれば、利用者が毎回すべてを細かく指定しなくても、ある程度は次を支援すべきでしょう。

• 曖昧な要件を検出する

• 確認すべき質問を提案する

• 完了条件を整理する

• テスト不足を警告する

• 変更範囲を分かりやすく示す

• 危険な操作では承認を求める

• 問題が起きたら元へ戻せるようにする

「誰が悪いか」と一人へ責任を集めるのではなく、役割ごとに分けて考える必要があります。

モデル提供者には、基礎能力、指示追従、安全性を改善する責任があります。

エージェント製品には、ツール制御、状態管理、権限、監査、使いやすさを設計する責任があります。

導入する企業には、利用ルール、教育、評価、責任分担を整える責任があります。

利用者には、目的、資料、確認条件を伝え、結果を適切に判断する責任があります。

高リスクな領域では、専門家や管理者が最終承認を行う必要があります。

問題が起きたときに必要なのは、犯人探しではありません。

どのレイヤーで失敗したのかを特定し、そこを直すことです。

AIが失敗したら、この7段階で確認する

では、実際にAIの成果が悪かったときは、何から確認すればよいのでしょうか。

私は、次の順序で切り分けるのがよいと考えています。

1．要件と完了条件は明確だったか

何を作るのか。何を変更してよいのか。どの状態になれば完成なのか。

これらが曖昧なまま、AIへ判断を任せていなかったでしょうか。

2．必要な情報を渡していたか

既存コード、仕様書、参考資料、バージョン、過去の判断へアクセスできたでしょうか。

知らない情報を、AIが推測で補っていなかったでしょうか。

3．タスクを適切な大きさに分けていたか

調査、設計、実装、テスト、レビューを一度に任せていなかったでしょうか。

途中で方向を確認できる状態になっていたでしょうか。

4．正誤を判定する方法があったか

テスト、型検査、出典確認、再計算、チェックリストなど、成果を評価する方法はあったでしょうか。

AIが「できました」と言ったことを、そのまま成功と考えていなかったでしょうか。

5．失敗と途中状態を引き継げたか

前回なぜ失敗したのか。どの方針を採用したのか。何が未解決なのか。

長い作業の途中で、こうした情報が失われていなかったでしょうか。

6．そのAIに適した仕事だったか

暗黙知の多い大規模設計や、失敗時の影響が大きい本番操作を、無理に任せていなかったでしょうか。

現在のモデルが苦手な仕事を、得意な仕事と同じように扱っていなかったでしょうか。

7．同じ条件で、別のモデルや製品と比較したか

要件、資料、実行環境、評価方法をそろえたうえで比較したでしょうか。

特定のモデルだけが失敗するなら、モデルや製品の問題かもしれません。

どのモデルでも失敗するなら、要件や評価方法に問題がある可能性が高まります。

1から5に弱い部分があるなら、まず仕事の設計を改善します。

そこまで整えても、同じ失敗を繰り返すのであれば、モデルや製品の能力限界を疑う。

この順序で考えると、「AIはすごい」「AIは使えない」という感想から一歩進み、具体的な改善につなげられます。

これから重要になるのは、「よいプロンプト」より広い設計力

プロンプトが不要になるわけではありません。

目的や条件を、AIが理解できる形で伝える力は、これからも重要です。

ただ、長く丁寧な指示文を書くだけでは、複雑な仕事を安定して任せることはできません。

今後、より価値が高まるのは、次のようなことを設計できる人だと思います。

• 何をAIへ任せるか

• 何を人間が判断するか

• どの情報を、どの順序で与えるか

• どの状態を完成とするか

• 何を使って正しさを確認するか

• 失敗したら、どの工程まで戻るか

• どのモデルとツールを使い分けるか

• 途中の判断や作業状態をどう残すか

• どの操作で人間の承認を必須にするか

ハーネス設計、評価設計、コンテキスト設計、エージェント・オペレーション設計。

呼び方はいろいろあります。

ただ、名前を覚えることが本質ではありません。

AIを単体の回答装置として見るのをやめ、人間、情報、ツール、評価、権限、承認を含む仕事のシステムとして考える。

ここが、これからのAI活用では重要になるはずです。

「AIはしょぼい」でも、「全部ユーザーが悪い」でもない

現在のAIやコーディングエージェントは、すでに多くの仕事で十分に役立ちます。

一方で、長期的な作業、複雑な統合、暗黙知の多い業務、高い安全性が求められる領域では、まだ明確な限界があります。

だから、次の二つは、どちらも少し極端です。

私なら、次のように表現します。

成功したら「AIはすごい」。

失敗したら「AIは使えない」。

そう感覚だけで評価してしまうと、何を改善すればよいのかが分かりません。

同じ仕事、同じ情報、同じ環境、同じ評価方法で比べる。

そのうえで、どこに問題があったのかを切り分ける。

AI時代に必要なのは、AIを信じ切ることでも、最初から見限ることでもないと思います。

AIが間違えることを前提にする。

そして、間違いを発見し、修正し、安全に価値へ変えられる仕事を作る。

それだけでも、「AIは使えない」と感じていた仕事の一部は、大きく変わるかもしれません。

参考資料

• Google DeepMind「AlphaEvolve: A Gemini-powered coding agent for designing advanced algorithms」

• Anthropic「Demystifying evals for AI agents」

• METR「Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity」

• METR「We are Changing our Developer Productivity Experiment Design」

• Xu et al.「AI-assisted Programming May Decrease the Productivity of Experienced Developers by Increasing Maintenance Burden」

• Huang et al.「Professional Software Developers Don't Vibe, They Control」

• Sankaranarayanan「Mitigating “Epistemic Debt” in Generative AI-Scaffolded Novice Programming」

• Thai et al.「SWE-EVO: Benchmarking Coding Agents in Long-Horizon Software Evolution Scenarios」

• OWASP「Top 10 for Agentic Applications 2026」

※本文で紹介した研究には、プレプリント、観察研究、特定条件下の実験が含まれます。個別の研究結果を、すべての開発者、企業、AI製品へそのまま一般化するものではありません。