AI は強力なツールですが、万能ではありません。成果はユースケースに大きく左右されます。強みと弱みを把握することが、適切に使う鍵です。
タスクに AI を使うかどうかを決めるときは、次の原則を指針にしてください。
- フィードバックループが最重要です: 成功を左右するいちばん大きな要因は、フィードバックループです。出力をどれだけ早く簡単に検証し、ハルシネーションを直せるかです。主観的な文章より、コードやスクリプトのほうが正しさを検証しやすいです。
- 付加的なタスクを優先します: AI は一般に、これまでできなかった、またはやらなかった新しいことのような付加的なタスク向きです。事業を回し続けるための運用タスク向きではありません。
問題を解く、またはプロセスを効率化する目的で AI を検討する前に、次の質問をします。
- 手作業の繰り返し作業ですか。
- 手作業だと、何時間、何日、何週間かかりますか。
- まったく同じ 操作を何度も繰り返す必要がありますか。
- 対象を特定する、または操作を行うための明確なロジックがありますか。
- スケールするか、他の人も使えると役立ちますか。
これらの質問に yes と答えられるなら、AI ベースの解決策の有力な候補です。どれかに no または I do not know と答える場合は、まず現行プロセスを進め、AI がまだ役立つ小さい具体的な箇所を探します。
AI が明らかにプラスで効果的だった領域です。
これが、いちばん成果が大きく、推奨するユースケースです。
- うまくいく理由: ハルシネーションを簡単に「テスト」できるときに AI は最も力を発揮し、コードは検証しやすいです。
- 使う場面:
- ドキュメントの更新を自動化するローカルスクリプト（Vibecoding スクリプトなど）の作成。
- シンプルなドキュメントコンポーネントの生成。
- GitHub Actions の作成。
- 競合ドキュメント分析の支援。
- 主な利点: できたコードは自分たちのものになります。今後 AI モデルや価格が変わっても、安定して変わりません。
docs-as-code を使うチームでは、Windsurf や Cursor などの IDE に組み込まれた AI チャットが、複数の変更を効率よく進めるのに非常に有効です。
- うまくいく理由:
- AI がコードベース（この場合はドキュメント）から大量のコンテキストを理解できます。
- ハルシネーションを見つけて直すフィードバックループが非常に短いです。
- Git 連携のおかげで、ハルシネーションを見つけてレビューし、取り除きやすいです。
- 主な利点: 何日、場合によっては何週間もの作業を削減できます。同じ作業を繰り返す大規模なドキュメント更新では、AI 対応 IDE でプロセスを大幅に効率化できます。
- 注意: まず regex などのより単純な解決策を検討してください。多くの場合、そちらのほうが良く、速く、安価です。大きなタスクを力技で進める必要があるときや、複雑さが高いときに AI を使います。
見込みはあるものの、実装に注意が必要な領域です。
ステークホルダーが、テクニカルライティングチームへ渡す前に、ドキュメントの 初稿 を AI で作ることは、前向きに捉えています。
- 主な価値: AI が作った下書きそのものの品質は、まちまちなことが多いです。いちばんの価値は、ステークホルダーがドキュメントを製品の一部として（製品と切り離さずに）考える強制的なきっかけになることと、忙しいステークホルダーからテクニカルライティングチームへ重要な情報をできるだけ早く共有できることです。
- 理由: 下書きを作るには、依頼者が必要な背景情報を先に集める必要があります。この情報を最初に受け取れることは、テクニカルライティングチームにとって大きな利点です。
- アクション: こうした依頼の組み立て方は、プロンプトテンプレート を参照してください。
顧客向けチャットボットの経験は、まちまちです。
- 利点: たまに優れた回答を返します。
- 欠点: ハルシネーションを防ぐため、ボットを「確信度が高いときだけ答える」ようにすることが多いです。その結果、回答を拒否します（例: "I don't know"）。ユーザーはこれを嫌います。一方で、ハルシネーションも嫌います。実際のユーザー体験を意識し、ドキュメントチャットボットへのエンゲージメントと成功を追跡する方法を用意してください。結果次第では、今後のハルシネーションを防ぐために埋めるべきドキュメントのギャップが見つかることがあります。
- 代替: 現時点では、AI 搭載の検索と類似度スコアの可能性のほうに、より期待しています。こちらのほうがコントロールしやすいと感じます。ただし、Cloudflare 内およびサードパーティアプリ経由で、ドキュメントがチャットボット体験にどう良い影響を与えられるかは、まだ検証と追跡中です。
これまでの経験から、現時点では次のユースケースは推奨しません。
プルリクエスト経由でコンテンツ変更（文法、書式など）を自動提案するボットでは、成果が出ていません。
- うまくいかなかった理由:
- フィードバックループが遅い: GitHub の PR という文脈では、ハルシネーションを直すフィードバックループが非常に遅く、難しいです。
- エンゲージメントが低い: 検証に手間がかかりすぎるため、自チームでも PR を閉じたり無視したりすることが多いと分かりました。
- コントリビューターの混乱: 受信した PR の問題を指摘する同様のボットは、コントリビューターを困らせ混乱させ、提案の多くがハルシネーションでした。