AIが「できない」と言ったとき、どこを直せばいいのか

AIが「できない」と言ったら、指示・権限・接続を分けて確認すると、直す場所を間違えにくくなります。

AIにブラウザ操作やファイル保存まで任せていると、急に「できません」と返ってくることがあります。そこで最初にプロンプトを書き直す。権限を広げる。設定を触る。僕も何度かそうしてきました。

ただ、同じ「できない」でも原因は一つではありません。僕の手元では、実際に三つの別問題が同じ言葉に見えていました。対象と操作の指定が足りない「指示」の問題。重要な操作を実行してよいと明示されていない「権限」の問題。そして、そもそもAIからブラウザや外部サービスへ届く道がない「接続」の問題です。

先に判断材料を置くと、僕は今この三つを次の順で切り分けます。

そのAIから必要なツールや接続先が本当に見えているか。
見えているなら、実行しようとしている操作が許可されているか。
そこまで通っているなら、対象・操作・完了条件の指示が具体的か。

順番が大事です。接続がないのに文章を磨いても動きません。許可が必要な操作を、設定変更で無理やり通すのも違います。逆に、接続も権限もあるのに対象が曖昧なら、最後に直すべきなのは指示です。

「できない」を一種類のエラーとして扱わない

2026年8月、僕はAIからGitHubへの外部通信が止まる場面を何度か経験しました。「許可するからやって」と返しても通らないのに、「GitHubへプッシュしてください」のように対象と操作を具体的にすると進んだケースがありました。

このとき僕は、問題をかなり「具体的な許可」の側に寄せて理解していました。実際、このケースではそれで通った。だからその観測自体は残っています。

でも、その後に別の失敗がありました。2026年9月、前の実行ではできていたブラウザ上の画像アップロードを、次の実行環境では「できない」と判断されたことがあります。最初はブラウザ設定やファイル選択の制約が疑われました。

ところが、履歴を追うと大きな差はそこではありませんでした。前の実行環境にはブラウザを操作する接続があり、次の実行環境にはその接続が見えていなかった。接続のある環境では、アップロード用の入力欄を見つけ、画像ファイルを渡し、アップロード後の画像サイズまで読み戻せています。

つまり、「できない」という出力だけを見れば似ていても、8月は許可の出し方が効いたケース、9月は実行経路そのものが無かったケースでした。この二つを同じ対処法で直そうとすると外します。

まず接続を、軽い読み取りで確かめる

一番最初に見るのは、「そのAIが何へ触れる状態なのか」です。

たとえばGoogle Driveへ保存させたいなら、いきなりファイル作成を試すより、指定したフォルダの名前を一つ読む。ブラウザを操作させたいなら、現在のページ情報を読む。本人限定のデータを使うなら、軽い一覧取得を一件だけ試す。壊さない読み取りで道が通っているかを見る方が切り分けやすいです。

ここで読み取り自体ができないなら、長い指示を書き足す前に接続側を疑えます。逆に読み取りが成功すれば、「サービス全体に届かない」という仮説は弱くなります。

僕が9月にハマったケースでは、この確認を先にやればかなり早く気づけました。ブラウザへの接続がない実行環境で、ブラウザ設定を直そうとしても目的の操作には届きません。原因がない場所を直し始めるから、作業だけが増えます。

ここで注意したいのは、ツール名が画面に見えないだけで、外部サービスそのものが落ちたと決めないことです。実行環境側でツールが読み込まれていないのか、認証が切れているのか、通信そのものが失敗しているのかは別です。実際の読み取りを一度行い、返ってきたエラーまで見てから名前を付ける方が安全です。

次に権限を見る。「できる」と「やってよい」は別です

接続があるのに止まるなら、次は権限です。

AIが技術的には操作できても、削除、共有、課金、公開、外部送信のような行為は、本人の明示的な承認が必要になることがあります。このとき「フルアクセスっぽいから全部できるはず」と考えると、技術的な能力と許可を混同します。

僕の8月の記録では、外部通信で止まったとき、抽象的な「許可します」より「GitHubへプッシュしてください」のように対象と操作を特定した言い方で進んだケースがありました。ここから僕が今残している教訓は、「AIは必ず特定のキーワードで動く」という一般法則ではありません。そこまでの証拠はありません。

使えるのはもっと狭い部分です。重要な操作で止まったら、何を・どこへ・どの操作まで許可するのかを明示する。逆に、本人の承認が必要な操作をAI側の工夫だけで迂回させない。この二つです。

例えば「このフォルダを整理して」より、「このフォルダ内の重複候補を一覧化して。削除はしない」の方が、許可範囲と禁止範囲が分かれます。「公開して」より、「下書き保存まで。公開はしない」の方が、どこまで任せるのかが明確です。

最後に指示を直す。対象・操作・完了条件の三つを見る

接続があり、権限も足りている。それでも仕事が進まないなら、ここで初めて指示そのものを疑います。

僕が見るのは三点です。

対象は何か。どのファイル、どのページ、どのフォルダ、どのアカウントを触るのか。

操作は何か。読むのか、書くのか、置き換えるのか、保存するのか。

完了条件は何か。ファイルを作っただけで終わりなのか、保存後に読み戻して中身まで一致したら終わりなのか。

この三つが曖昧だと、AIは途中まで正しく動いても、こちらの「終わった」と一致しません。特にエージェント型の作業では、「作成成功」と「目的達成」が別になりやすいです。Driveにファイルを置けても、中身が空なら完成ではない。ブラウザで投稿画面を開けても、公開後のページを確認していなければ配信成功とは言えません。

だから指示を細かくする目的は、AIを縛ることではなく、判定できる仕事にすることだと思っています。何十個も禁止事項を足すより、「何を変えたいか」「どこまでやれば終わりか」が分かる方が効きます。

60秒で切り分けるなら、この順で見る

実際に止まったとき、僕なら次のように確認します。

まず、壊さない読み取りを一回だけ実行します。対象サービスやブラウザから何か一つ取得できれば、接続経路は少なくとも一部通っています。取得できなければ、指示を書き換える前に、接続・認証・実行環境のどこで止まったかを確認します。

次に、その操作が本人の承認を必要とする種類かを見ます。削除、公開、課金、権限変更のような操作なら、承認の有無と範囲を分けます。承認済みなら、何へのどの操作を許可したのかが分かる形にします。

最後に、対象・操作・完了条件を一文で言えるか確認します。「Driveをいい感じにして」ではなく、「指定フォルダへ6ファイルを原形式で保存し、保存後に6件を読み戻して内容とIDを確認する」なら、途中で何が失敗したかも分かります。

この順番にすると、対処と原因が対応します。接続の問題には接続を戻す。権限の問題には必要な範囲だけ承認する。指示の問題には対象・操作・完了条件を具体化する。直す場所が一つずつ狭まります。

それでも三つで説明できない失敗はある

もちろん、すべてのエラーがこの三分類で解決するわけではありません。サービス側の障害、利用上限、ツール自体の不具合、モデルの誤認、規約上できない操作などもあります。

だからこの方法は「原因は必ず三つのどれか」と断定するものではなく、最初の誤診を減らすための入口です。三つを確認して全部通っているなら、その時点で初めて別の技術障害やサービス側の状態を疑えばいい。

僕自身、8月の成功体験だけを見ていたら、「具体的に許可すれば通る」という説明に寄せたままだったと思います。9月に接続そのものが無いケースを踏んで、同じ「できない」を同じ原因だと思わない方がいいと分かりました。

AIに仕事を任せる量が増えるほど、失敗をゼロにすることより、失敗した場所を早く特定できることの方が効いてきます。プロンプトを直す前に、まずそのAIが目的地まで道を持っているかを見る。僕は今、そこから確認しています。