AIに何を渡すかで、答えは変わる

「うちのサービスを紹介する文章を書いて」。人に頼むときも、この一言だけでは迷うはずです。誰向けなのか、何が強みなのか、料金を載せてよいのか。AIにも、その仕事に必要な前提を渡す必要があります。

ただ、社内の資料を全部渡せば解決するとも限りません。古い案と現在の仕様が混ざっていたら、どちらを採用すればよいでしょうか。今回は、情報の量だけでなく、選び方と位置づけを考えます。

コンテキストエンジニアリングでは、AIが回答するときに参照する指示、資料、会話履歴、道具から得た情報などを選び、管理します。Anthropicは、必要な情報を十分に保ちつつ、関係の薄い情報を増やしすぎないことを重視しています。Anthropic「Effective context engineering for AI agents」

ここからは、その考え方を記事づくりに応用した、Sofriaからの提案です。特別なシステムを導入する前に、チャットへ渡す依頼メモを整えてみます。

前回と同じ、架空の「まちのWeb相談室」を使います。例示用の資料Aで確定しているのは、小規模事業者向けのWeb制作、相談後の個別見積もり、公開後の更新は別契約という三点です。実在するSofriaのサービス条件ではありません。

この資料に加えて、以前の企画メモに「更新まで含めた定額制も検討」と書かれていたとしましょう。二つの文書を区別せず渡すと、検討段階の内容が紹介文に入り込む余地をつくってしまいます。

資料には、内容だけでなく役割を付けます。「資料Aは現行の確定仕様」「メモBは未採用案で、掲載根拠にしない」。文体の参考として他社の記事を渡すなら、「言い回しや構成の参考であり、実績や料金は転用しない」と添えます。

資料の新しさだけで優先順位を決めるのも避けたいところです。更新日が新しくても、まだ承認されていない案かもしれません。版、承認状態、適用範囲を確認してから渡します。

次のメモは、架空サービスの記事を書くための例です。自分の仕事に置き換えるときは、資料名と条件を実際のものへ変えてください。

依頼文の末尾には、「資料同士が矛盾する場合は、どの記述が衝突しているかを示して保留してください」と加えます。AIに都合のよい説明を選ばせるより、矛盾が見える状態を保つためです。

サービスによっては、リンクを渡してもページを取得できない場合があります。資料を読めた前提で進めず、参照した文書名と該当箇所を示してもらい、自分でも照合してください。出典らしい文字列が出たことだけでは、確認は終わりません。

何度も相談しているうちに、最初の案、修正案、却下した案が会話に残ります。「さっきの方針で」と頼む前に、現在の決定事項を短くまとめ直してみてください。

残すのは、目的、確定した仕様、使う資料、未解決の点です。特に「料金は未確認」「定額制案は採用しない」といった保留・却下の理由は、要約のときに落としたくない情報です。まとめた内容も、元の資料と見比べます。

長い会話を要約すれば必ずよくなるわけではありません。必要な条件まで削ってしまえば、かえって仕事がずれます。短さそのものを目標にしないことが大切です。

顧客の個人情報や契約上の機密を、試しやすいからという理由で入力しないようにします。利用するサービスの契約・管理設定と、自社の取り扱いルールを確認し、例示用の情報で試す方法もあります。

最後に、依頼メモを付ける前後で同じ確認表を使ってみてください。根拠のない料金が減ったか。別契約の条件が残っているか。資料を整える時間も含めて、確認の負担がどう変わったかを見ます。

必要な情報を渡せたら、次はAIがそれを使って仕事を進める環境です。資料を読む道具、保存場所、操作できる範囲を考えていきます。