はじめに
こんにちは。とまと🍅好きのエンジニアです！
最近は趣味でAIを自律的に動かしてみて、いろんなことに取り組んでいます。
今回はその中で、失敗したことがあったので、それを記事にしようと思います。
話は少し変わりますが、最近「AIっぽいもの」が増えてきましたね。
飲食店のメニュー、ポスター、資料とかいろんなところで見るようになってきました。
もちろん文章でもAIっぽいものが多いです。
Qiitaでも「AIっぽさ」を無くす方法がいろいろ紹介されています。
そこで、自分は「AIっぽさ」を無くすために、まず何がAIっぽいのかを調べようと、Claude Codeを使って調査・分析をしていました。
しかし、調査が終わると全く意味のない、調査・分析になってしまって時間とトークンが水の泡になってしまいました😢
この記事では、なぜそうなったのかを振り返り、そこからどういう風に改善していくのかということを書いていこうと思います！
この記事の対象読者
- ClaudeCodeを使いだしたけど上手くエージェントが調査・分析をしてくれないと悩んでいる方
注意
この記事では「AIっぽさをなくす」ための方法については記載していません。AIエージェントを使って調査・分析をする際にどんな考え方が重要なのかを個人的に考察した内容になっています。
背景
調査の中身は、人間の文章と AI の文章を比べて、「人間らしさ／AIらしさ」を決める特徴を探すものです。具体的には、青空文庫などで公開されている人の書いた文章と、同じお題で AI に書かせた文章を比べるということをしました。
ただ正直なところ、この調査は意味のある成果になりませんでした。
調べること自体はできましたが、「それで何が分かれば成功なのか」を決めていなかったので、集めた情報を次の判断につなげられていませんでした。
どんな調査をしたのか
今回はClaudeCodeに自律的に調査・分析をしてもらいたいという思いがあったので、そうなるように指示や環境作り（ACTIONSやFLOW等の計画書等の用意）を行って進めていきました。
- 目的（人間らしさを調査してほしい）をClaudeCodeに入力し、自律的に分析・調査を進めてもらうよう指示した
↓ - 人間らしさ・AIらしさの候補になる特徴を約40個リストアップ
↓ - 人の文章26件（青空文庫の作品が中心）と、同じお題でAI（Claude、Gemini 2種）に書かせた文章162件を収集
↓ - 特徴ごとに、同じお題の人間版とAI版を比較
分析の結果
人とAIの文章で違いとして出たのは、文の長さ・行の長さのばらつきでした。
次いで、定型句、価値語（「大切」「重要」のように評価を表す語）、一人称の使用頻度に違いがありました。
一方で、よく言われる次の3つにおいては特に違いがありませんでした。
- 語彙の均質さ
- 接続詞の連発
- 文末の単調さ
これだけみると良い感じの調査をしてもらっていそうです。
ただ、自分が知りたかったのはそんなことではないと気づきました。
なぜなら、自分は青空文庫の作品とAIが書いた文章の違いを知りたいわけではないからです。
比較の土台に問題があった
結果以前に、比較自体が問題でした。
問題点
人のデータとして持ってきたのが明治から昭和前半に書かれた作品が多かった
青空文庫の著作権切れのデータを探していたせいで、気づいたら古い年代の文章を集めてしまっていました。
そのため、差が「人間とAIの違い」なのか「時代や文体の違い」なのか、切り分けられず、今回の目的には使えない調査になってしまっていました。
原因：目的を絞らずに、データを集めてしまった
原因は、調査の入り口で目的を絞り込めず、その目的から「どんな人間の文章が必要か」を逆算できなかったことです。つまり、自分が知りたいこと（現代の書き手の文章）が、AIに伝わっていないまま進めてしまっていました。
| 足りなかったこと | 起きたこと |
|---|---|
| ゴールが広すぎた | 「AIっぽくないモノ」では、「誰のどんな文章を人間らしいとするか」が決まらず、基準がないままデータを集めた |
| 目的からデータを逆算できていない | 集めやすい青空文庫とウィキペディアから選んだ結果、青空文庫に偏った |
| 分析の目的を置いていなかった | 「このデータで答えが出せるか」を分析前に確かめられず、差を切り分けられないと気づいたのは分析の後だった |
目的を先に深掘りしていれば、「現代の人間の文章が必要」と実行前に分かりました。そうすれば、そのデータを別の場所（現代の人が書いたブログなど）から集める選択肢も取れたはずです。
AI は、与えられた目的をそのまま実行します。だから、目的が広いままだと、実行はできても結果の価値は保証されません。
どうすべきだったか
実行の前に、目的を次の順で深掘りすべきでした。
- 目的を絞る: 広い目的は、達成条件が言える状態まで分解する
- 分析の目的を決める: 「何を明らかにするための分析か」を一文で書く
- 必要なデータを考える: その目的に合うデータは何かを先に決める
- 集め方を決める: AI が自分で集められるデータかを判断し、集められないものは人に集めてもらう
- 環境を整える: 目的の達成に必要な環境とデータをそろえてから、初めて実行に入る
今回は、AIは順番を飛ばして実行に入っていました。青空文庫の調査が無駄になったのは、手順1〜3を経ずに、手順5に進んだからです。
スキル改良
そこで、プロジェクトを始めるときに使っている自作のスキル（Claude Code に読み込ませる手順書）を改良しました。方針は、AI が作業を始める前に、「何ができれば成功か」と「そのために何が必要か」を、スキルが自分で確認して書き出すことです。
その際に、OpenAIやAnthropicなどの公式ガイドや、公開されているツールではどう対策しているのかを調べて、それらも組み込みました。
（参考にした資料は、記事の最後にまとめています）
調べると、以下のことが分かりました。
- 多くが「質問で目的を絞る → 計画にする → 人が確認する → 実行する」という流れになっている
- 成功の基準を、先に決めさせる点も共通している
今回の失敗は、調べたい相手と手元のデータが合っているかを確かめる工程が、抜けていたことでした。そこで、実行の前に次の4つを書かせるようにしました。
-
調べたい相手と、手元のデータを比較:
たとえば「現代の人が書いた記事」を知りたいのに、「青空文庫に掲載されている昔の作品」なら、ずれがあります。その際は、「それでも使う理由を書く」「結論の範囲を狭める」「人に確認する」のどれかを必ず選ばせるようにしました。 -
成功したかどうかを、他の人が判断できる形で書く:
別の AI や人が成果物を見て、それで目的を達成しているかを判断できるようにしました。 -
必要なものと、誰が用意するかを決める:
データ、素材、API キー、アカウントなどを、AI が自分で用意するか、人に頼むかに分けました。人に頼むのは最後にして、API キーのような鍵は AI が取得できない設定にしました。 -
本番の前に、小さく試す:
失敗しそうな理由を3つ書き（1つは「手元のデータが、調べたい相手と違った」）、少量だけ先に動かしてみるようにしました。
作業の大きさで、確認の量を変える
また、毎回すべてやると、少しの作業まで重くなってしまいます。仕様を細かくしすぎると、何も決めずに AI に頼む方が速かった、という報告もあります（参考資料の Martin Fowler のサイト）。そこで、作業の大きさ、重さで確認の量を変えました。
| 作業の大きさ | 例 | 確認すること |
|---|---|---|
| 小さい | 1回で終わる、やり直せる | 3つだけ（成功したか判断できるか、人にしか用意できないものはあるか、一番ありそうな失敗は何か） |
| ふつう | 複数の作業がある、外部のサービスやデータを使う | 上の4つ |
| 大きい | 調べた結果で結論を出す、公開やお金が絡む | 上の4つに加えて、手元のデータを実際に読んで確かめる |
迷ったら「小さい」にします。調査だけでなく、アプリ開発など他の作業にも同じ流れで使えるようにしました。
未解決の課題
一方で、深掘りをどこで止めるか、データをどこまで集めるかは、調べても決まった基準は見つかりませんでした。
-
深掘りをどこで止めるか:
「何問まで聞けばよい」という基準には答えがありません。他の取り組みでも、質問数の上限も、3〜6問、最大5問等ばらばらでした。なので、回数ではなく、次の3つが揃ったら止めることにしました。- 他の人が成功していると客観的に判断できる
- 調べたい対象（目的）と準備する予定のデータが一致している
- 次の質問の答えによって、計画が変化しない
-
データをどこまで集めるか:
目安は分野で異なるそうです。AI を評価する場面では、実際の失敗例から20〜50件で始め、結論を出すときは、見つけたい差の大きさから必要な数を逆算する、というやり方があるようなので、今後試していこうと考えています。
おわりに
今回の調査は期待どおりの成果にはなりませんでしたが、目的を深掘りし、必要な環境とデータを先に準備するという教訓を得ました！つまり、AI に任せる前の準備って大事なんだと改めて実感しました。
深掘りとデータ収集の範囲をどう決めるかは、改良したスキルを実際に使いながら試していきます！今後もこのスキルについて記事にできたらと思います！
同じように、AI に調査や分析を任せてうまくいかなかった人のヒントになれば嬉しいです！🍅
参考にした資料
スキルの改良は、次の資料を参考にしました。
- Spec Kit の clarify: 質問は最大5問、1度に1問、途中で「done」と言えば終わる
- OpenAI Cookbook（Deep Research API）: あいまいさを最も減らす3〜6問に絞って聞く
- Best practices for Claude Code: リポジトリを読んで分かることは書かず、分からないことだけを人に聞く
- Prompt engineering overview と Devin の指示の書き方: 成功の基準を先に決める。「ちゃんと動くように」ではなく、確かめられる形で書く
- Datasheets for Datasets: データの目的・中身・集め方を、使う前に書き出す
- Spec-Driven Development の3ツールの比較（Martin Fowler のサイト）: 仕様を重くしすぎると、小さな作業でかえって遅くなる（1人の体験記です）
- Ambig-SWE: AI は指示が足りているかの判断が苦手で、質問して答えをもらうと成績が上がる
- Demystifying evals for AI agents と Adding Error Bars to Evals: 評価は実際の失敗から20〜50件で始め、結論を出すときは検出したい差から必要な数を逆算する