AIの「できます」を信じるな — 一次情報に当たる技術

はじめに

AIに何かを相談すると、たいてい「できます」と答える。自信満々に。

しかし、その「できます」をそのまま信じて突き進むと、何時間もハマった挙句「やっぱりできませんでした」にたどり着くことがある。

これはAIが嘘をついているのではない。AIは質問されたことに対して、最もそれらしい回答を生成する構造になっている。「できますか？」と聞けば「できます」と答えやすい。技術的な壁やAPI制約を踏まえた「正直な」回答を引き出すには、聞き方と検証の技術が必要だ。

この記事では、AIの回答を検証するための4つの考え方を紹介する。

---

裏取りの習慣 — 公式ドキュメントで確認する

AIは学習データに基づいて回答を生成するが、学習データには期限がある。ライブラリやフレームワークのAPIは日々更新されるため、AIの「知識」と現在の仕様が食い違うことは日常的に起こる。

あるAI活用コミュニティで印象的な場面があった。コミュニティで使っていたAIコーディングツールのUIが、セッションのたびに変わるほどの速度で進化していた。講師の画面と参加者の画面でボタンの位置が違い、「あれ？そんなボタンありましたっけ？」という場面が頻発した。ツールの進化速度がAIの学習速度を超えているのだ。

AIが「このメニューから設定できます」と案内したとしても、そのUIが3ヶ月前のものである可能性がある。これはAIの性格の問題ではなく、構造上の限界だ。

裏取りの具体的な方法

1. 公式ドキュメントを読む

AIの回答を鵜呑みにせず、該当するライブラリやAPIの公式ドキュメントで確認する。AIに「公式ドキュメントのURLを教えて」と聞くのも有効だ。ただし、AIが教えてくれたURLが正しいかどうか自体も確認が必要になる。

2. バージョンを確認する

AIが想定しているバージョンと、自分が使っているバージョンが一致しているか確認する。「v3での書き方」と「v4での書き方」が全く異なるライブラリは珍しくない。

3. 「本当にできますか？制約はないですか？」と聞き直す

質問の仕方を変えるだけで、AIの回答の精度が変わることがある。「できる前提」で話を進めるのではなく、「できないケースはありますか？」「この方法に既知の問題はありますか？」と問いを立て直す。

ある運用の工夫として、AIに対して「自分の知識が古い可能性を前提に、公式ドキュメントを確認してから回答するように」とルールファイルに書いておくと、AIの自己補正が働きやすくなる。自分の知識の限界を意識させることで、より謙虚な回答を引き出せる。

---

「誰もやってないなら壁がある」の嗅覚

AIに「LINEボットでGoogleカレンダーと同期する機能は作れますか？」と聞いたとする。AIは「できます」と答え、具体的なコードまで提示してくる。

あるコミュニティのメンバーがまさにこの状況にハマった。AIが「あと一歩です」「もう少しで完成します」と言い続ける中、8割まで完成させた。しかしコミュニティの場でこの進捗を共有したとき、他のメンバーから冷静な指摘が飛んだ。

「LINEでそれをやってる事例、見たことないですよ」

「みんなやりたいと思っているのに今ないということは、技術的に壁があるんじゃないですか」

この一言で状況が変わった。調べてみると、LINE Messaging APIの仕様上、技術的な制約が存在する可能性が浮上した。

「誰もやってないなら壁がある」の考え方

世の中にサービスや事例が存在しないものは、技術的な壁がある可能性が高い。

「みんなやりたいと思っている」のに「誰も実現していない」なら、それは理由がある。需要はあるのにサービスが存在しないとき、その空白は技術的・法的・コスト的な障壁を示唆している場合が多い。

AIは「できない」とは答えにくい構造を持っている。「できますか？」と聞かれると「できます」と答えやすいし、「これはどうですか？」と聞かれると「良い案です」と答えやすい。だから人間側が「本当にできるのか」を検証する必要がある。

検証の第一歩は「その組み合わせを実現している事例が実際に存在するか」を調べることだ。GitHubでの実装例、ブログ記事、公式のサンプルコード — これらが豊富にあるなら実現可能性は高い。検索してもほとんど見当たらないなら、壁がある可能性を疑うべきだ。

講師のアドバイスは明確だった。「できるなら、できると言っている根拠をしっかり確認すべき。突っ込んでできなかったらもったいない。」

時間は有限だ。方向を確認してから走るのと、走りながら確認するのとでは、手戻りのコストが根本的に違う。

---

デバッグ力＝伝達力 — 何が起きたかを伝える技術

エラーが起きたとき、AIに助けを求める場面は多い。しかし、何が起きたかを正確に伝えられなければ、AIも正確な解決策を出せない。

あるコミュニティでは「おま環（お前の環境だけの問題）で片付けるな、画面を見ろ」が合言葉になっていた。オンラインやチャットだけでエラーを説明しようとすると情報が不足するが、実際に画面を見せ合えば「あ、ここが違うじゃん」と一瞬で原因が特定できる。

これはAIとの対話でも同じだ。AIには画面が見えない。「エラーが出ました」と伝えるだけでは、AIは何も判断できない。「どんなエラーが」「どんな操作のあとに」「どんな環境で」出たのかを伝えて初めて、AIは的確な診断ができる。

AIへのエラー報告の作法

1. エラーメッセージをそのまま貼る

自分の言葉で要約しない。原文が最も情報量が多い。「なんかエラーが出ました」より「Cannot read properties of undefined (reading 'map')」のほうが、AIは正確な原因を推定できる。

2. 何をしたかを時系列で書く

「Aをした → Bが表示された → Cを試した → Dのエラーが出た」という流れを伝える。AIは文脈から原因を絞り込む。順序の情報が欠けると、推定に無駄が生じる。

3. スクリーンショットを渡す

文字情報だけでなく、画面の状態をそのまま見せる。ターミナルの出力、エラーダイアログ、ブラウザの開発者ツール — 画面には文字情報以上の手がかりがある。

4. 環境情報を添える

OS、ツールのバージョン、設定ファイルの内容を一緒に渡す。「私の環境ではこう設定されています」という情報が、一般的な回答ではなく具体的な回答を引き出す。

デバッグ力とは、プログラムを直す力ではない。何が起きたかを正確に伝える力だ。 伝達の精度が高ければ、解決策はAIでも人間でも迅速に得られる。逆に言えば、どんなに優秀なAIでも、不完全な情報から完全な答えは出せない。

---

「APIはあるか？」を最初に調べる

何かやりたいことがあったとき、最初に調べるべきはAPIの存在だ。

API（Application Programming Interface）とは、外部のサービスやツールと連携するための窓口のこと。Googleカレンダーのデータを取得したいならGoogle Calendar API、Slackにメッセージを送りたいならSlack API、というように外部サービスへの「接続口」がAPIだ。

なぜAPIを最初に確認するのか

APIがなければ自動化できない。

どんなに優れたAIでも、APIという窓口がないサービスのデータを取得したり操作したりすることは基本的にできない。「このサービスと連携したい」と思ったとき、そのサービスにAPIが公開されているかどうかが、実現可能性を決定する第一条件だ。

APIがあっても制約がある。

「このAPIは読み取りはできるが書き込みはできない」「1日のリクエスト数に上限がある」「特定のプランでないと使えない機能がある」といった制約を事前に把握することが重要だ。作り始めてから制約に気づくと、設計から作り直しになることがある。

AIに聞く前に自分で確認する。

「このサービスにAPIはありますか？」とAIに聞くこともできるが、AIの知識が古い可能性がある。公式サイトのドキュメントページ（たいていは「Developers」「API」「For Developers」というリンクがある）を自分で確認するのが確実だ。

あるコミュニティでは、健康診断のデータをAIに分析させる試みが紹介された。PDFやスキャン画像をAIに渡してデータ化するアプローチだ。ここでの教訓は一次情報（元データ）の質が、AIの分析精度を直接決めるということだった。

きれいなPDFと手書きのスキャン画像では、AIの読み取り精度が大きく変わる。「AIに読ませれば何とかなる」のではなく、「どんなデータをどういう形式で渡すか」を先に設計することが、最終的な精度を左右する。

「APIはあるか？」「データの形式は何か？」「精度に影響する要因は何か？」— これらを最初に確認する習慣が、無駄な手戻りを防ぐ。

---

まとめ

AIの「できます」を信じるなとは、AIを信頼するなという意味ではない。AIの回答を検証する習慣を持てということだ。

4つの考え方を振り返る。

1. 裏取りの習慣: 公式ドキュメントで確認する。AIの知識には賞味期限がある
2. 見たことないものへの嗅覚: 世の中にない事例には、技術的な壁がある可能性が高い。「誰もやっていない理由」を疑う
3. デバッグ力＝伝達力: 何が起きたかを正確に伝えること。解決はその後に来る
4. APIの存在調査: 何かやりたいことがあったら、まずAPIの有無と制約を確認する

AIは強力なパートナーだ。しかしパートナーの言葉を鵜呑みにするのと、パートナーの提案を検証した上で信頼するのとでは、結果の質が根本的に違う。

「できます」を聞いたとき、次に聞くべきは「その根拠は？」だ。「事例はありますか？」だ。「制約はないですか？」だ。

AIを信頼するには、AIを検証する技術が必要だ。

---

関連記事

• AIコーディングツールに「取扱説明書」を書いたら、開発が変わった — AI出力の検証チェックリストと公式ドキュメント参照の実践
• AIとの対話術 — コンテキスト管理の実践 — 検証の前提となるAIのコンテキスト管理の考え方
• AIは「正しそうな嘘」を描く — 画像編集で検証プロセスが必要な理由 — 画像生成でのAI検証。テキスト生成の検証と対をなすシリーズ記事