※この記事は、2026年7月時点の自分のAI運用メモです。AIツールやCodexまわりの使い方は変わりやすいので、現時点の実感として読んでください。
最近、AIに任せる作業が少しずつ増えています。
ブログの下書きを作る。
INBOXを整理する。
WordPressに貼るHTMLを作る。
関連記事を選ぶ。
ファイルを読んで、次に触る場所を整理する。
ここまでは、もうかなり日常的になってきました。
さらに最近は、AIにレビューや検証の手伝いもしてもらうようになっています。
ただ、そこで少し引っかかったことがあります。
AIにテスト結果や確認結果を見てもらう時、失敗したという結果だけを見ると、直す場所を間違えることがある。
何かが失敗した時、ついこう思いがちです。
「作ったものが悪かったのかな」
「コードが間違っているのかな」
「AIの提案がズレていたのかな」
もちろん、本当に作ったものが悪い場合もあります。
でも、実際にはそれだけではありません。
実行環境が合っていなかった。
必要な依存関係が足りなかった。
テストのやり方がズレていた。
確認する前提が間違っていた。
こういう理由でも、テストは失敗します。
だから、AIにテスト結果を見てもらうなら、失敗の原因を3種類に分けた方がよさそうだと思いました。
作ったものの不具合。
実行環境の制約。
試験方法の問題。
この3つを分けるだけで、AIのレビュー結果をかなり扱いやすくなる気がしています。
「失敗しました」だけでは、次に直す場所が分からない
AIに作業を頼んだあと、検証までしてもらうと便利です。
動作確認をする。
エラーが出ないか見る。
想定した入力で試す。
HTMLやMarkdownの形式を確認する。
ファイル更新後に、変な文字が混ざっていないか見る。
こういう確認をAIが手伝ってくれると、人間側の負担はかなり減ります。
ただ、テストや確認で失敗が出た時に、結果だけ返ってくると少し困ります。
失敗しました。
エラーが出ました。
想定通りに動きませんでした。
確認できませんでした。
これだけだと、次に何をすればいいかが分かりません。
作ったものを直すべきなのか。
実行環境を整えるべきなのか。
テスト方法を変えるべきなのか。
そもそも確認できる範囲を見直すべきなのか。
ここが混ざると、修正が遠回りになります。
AIにレビューや検証を頼むなら、成功か失敗かだけではなく、失敗の種類まで返してもらった方がいい。
最近はそこをかなり意識するようになりました。
1つ目は、作ったもの自体の不具合
まず分けたいのは、作ったもの自体の不具合です。
これは一番分かりやすい失敗です。
コードの書き方が間違っている。
リンク先が違っている。
HTMLの構造がおかしい。
必要な項目が抜けている。
記事本文に、出してはいけない情報が混ざっている。
こういう場合は、作ったものを直す必要があります。
たとえば、WordPressに貼るHTMLを作ったのに、見出しがMarkdownの ## のまま残っていたら、それは成果物側の問題です。
関連記事にリンクを付ける運用なのに、ただのテキストだけになっていたら、それも成果物側の問題です。
この場合は、AIに「この成果物を直して」と言えばいい。
原因も対応も比較的はっきりしています。
ただ、失敗が全部この種類とは限りません。
ここを間違えると、本当は環境や確認方法が原因なのに、成果物ばかり直し続けることになります。
2つ目は、実行環境の制約
次に分けたいのは、実行環境の制約です。
これは、作ったものが悪いというより、試した環境の都合で確認できない場合です。
権限が足りない。
ネットワークに出られない。
必要なツールが入っていない。
外部サービスにログインできない。
ローカルでは動くが、今の実行環境では確認できない。
こういうことは普通にあります。
自分の場合も、Codexに作業してもらう時、環境の制約でできない確認があります。
ネットワークが使えない。
権限で弾かれる。
実ブラウザやログイン状態が必要になる。
特定の外部サービスをその場で確認できない。
この時に「確認できませんでした」とだけ返ってくると、少し判断しづらいです。
それは作ったものの不具合なのか。
それとも、今の環境では確認できないだけなのか。
ここはかなり大事です。
環境の制約なら、成果物を直すのではなく、確認方法を変える必要があります。
人間がブラウザで見る。
別の環境で試す。
未確認として公開前チェックに残す。
今できる範囲だけ確認済みにする。
こういう扱いになります。
AIに検証を頼む時は、「環境の制約で確認できなかったもの」を、失敗とは別に出してもらう方が安全だと思います。
3つ目は、試験方法や前提の問題
もう一つ分けたいのが、試験方法の問題です。
これは、作ったものも環境も悪くないのに、確認の仕方がズレている場合です。
想定していない入力で試している。
確認すべきファイルを間違えている。
古い条件でテストしている。
実際の運用とは違う前提で判定している。
テスト用の手順そのものが不十分だった。
こういう場合、成果物を直しても解決しません。
むしろ、間違ったテストに合わせて成果物を変えてしまう危険があります。
AIに検証してもらう時も、ここは起こり得ます。
たとえば、ブログ用のHTMLを確認する時、WordPressに貼る前提なのか、普通のHTMLファイルとして見る前提なのかで、見る場所が少し変わります。
関連記事の確認でも、ローカルのファイル名を見ているのか、実際の公開URLを見ているのかで意味が変わります。
ファイル整理でも、現役INBOXを軽くするのが目的なのか、rawから全部を要約するのが目的なのかで、正解が変わります。
試験方法や前提がズレていると、AIはそのズレた条件の中で真面目に評価してしまいます。
だから、失敗結果を見た時は、成果物や環境だけではなく、確認方法そのものも疑った方がいい。
ここをAIに返してもらえると、かなり助かります。
失敗の種類を分けると、AIへの次の指示が変わる
失敗の原因を3つに分けると、次にAIへ頼む内容も変わります。
作ったもの自体の不具合なら、成果物を直してもらう。
実行環境の制約なら、未確認事項として残すか、別の確認方法を考えてもらう。
試験方法の問題なら、確認手順や前提を見直してもらう。
この違いはかなり大きいです。
全部を「エラーが出たから修正して」で返すと、AIは成果物を直そうとします。
でも、本当は環境の問題だったら、成果物を直しても意味がありません。
本当は試験方法の問題だったら、むしろ余計におかしくなる可能性もあります。
だから、最近はAIに検証を頼む時、単に成功・失敗だけではなく、こう返してほしいと思うようになりました。
- 作ったものの不具合
- 実行環境の制約
- 試験方法の問題
- まだ判断できない未確認事項
ここまで分かれていると、人間側も次の判断をしやすいです。
AIの確認結果をそのまま信じるのではなく、確認結果の種類を見て扱えるようになる。
これが、実運用ではかなり大事だと思っています。
「AIが失敗した」ではなく、どこで失敗したかを見る
AIを使っていると、うまくいかなかった時に、つい大きくまとめてしまいます。
AIが失敗した。
このツールは駄目だった。
このやり方は使えない。
でも、実際にはもう少し細かく見た方がいいです。
指示が曖昧だったのか。
材料が足りなかったのか。
成果物が間違っていたのか。
実行環境で確認できなかったのか。
テスト方法がズレていたのか。
人間が見るべき場所を決めていなかったのか。
ここを分けると、次に改善できる場所が見えます。
これは、AIを責めるための分類ではありません。
むしろ、AIを使い続けるための分類です。
うまくいかなかった時に、全部を失敗として捨てるのではなく、どこで詰まったのかを残す。
そうすると、次のプロンプトやスキル、確認手順に戻せます。
自分がAIに任せる作業を少しずつ広げられているのも、この「どこで失敗したか」を残すからだと思います。
AIに検証を頼むなら、失敗ログの読み方まで決めておきたい
AIに作業を任せるなら、成果物だけでなく確認できる証拠が大事だと思っています。
さらに、AIエージェントを学ぶなら、どこで止めるか、どこを人間が確認するかも見たいと思っています。
今回の話は、その次です。
証拠が返ってきたとしても、その証拠の読み方が決まっていないと、直す場所を間違える。
失敗した。
だから直す。
これだけでは少し粗い。
作ったものが悪いのか。
環境の制約なのか。
試験方法がズレているのか。
まだ判断できないのか。
ここまで分けて、ようやく次の一手が見えます。
AIにテスト結果を見てもらうなら、失敗の原因を3種類に分けた方がよさそうです。
その方が、AIのレビュー結果を人間が扱いやすくなる。
そして、AIに任せる範囲を広げても、どこを直せばいいのかを見失いにくくなると思っています。
コメント