本文へ進む
attrip.知りたいを、つくって確かめる
メニュー

AIに「次は何をする?」と聞く前に、ゴールを渡す

公開日 · 更新日 · 5 MIN READ · 理解の記録

RECORD / 2026

AIに仕事を頼むとき、つい一手ずつ指示したくなる。「ここを調べて」「次はこれ」「もう一度直して」。でも、まとまった仕事では、こちらが毎回次の一手を決めるより、最初に何ができたら完成なのかを渡したほうが進みやすい。

この考え方のきっかけは、Anthropicの開発者向け記事「Getting the most out of Opus 5.5 in Claude and Claude Code」だった。読んで私が持ち帰りたいのは、AIを放任する話ではなく、目的、完成条件、止まる条件を先に渡し、結果を証拠で確かめるという順番だ。

元記事を書いたAddy Osmaniさん

著者のAddy Osmaniさんは、AnthropicでClaude Codeに携わるエンジニア。以前はGoogleでChromeの開発者向けツールやウェブの性能改善に長く関わっていた。本人のプロフィールにも、その経歴が紹介されている。

2026年9月22日に公開された元記事は、Opus 5.5に仕事を頼むときの指示、長い作業中の進め方、結果の確認方法をまとめたものだ。ここから先は、その助言を自分の作業に置き換えて考える。

一手ずつの指示が、仕事を細切れにする

たとえば「古いコードを新しい方式へ移行して」と頼む。AIが一部を直して「次はテストします」と返すたびに、こちらが「続けて」と言う。これでは作業の責任が会話の往復に分散する。

最初の依頼を、こう変える。

依頼文の例: 対象のコードをすべて移行し、不要になった旧コードを整理してください。関連テストを実行し、失敗したら原因を直して再実行してください。完成条件は、対象範囲の移行が終わり、テストが通り、変更点と未確認事項を報告できることです。対象外のファイルや公開環境には触れず、破壊的な操作や判断が分かれる変更の前に確認してください。

大切なのは「全部任せる」という勢いより、終点を具体的にすることだ。何を変えるかと同じくらい、何を変えないかも書いておく。

「よく考えて」より、判定できる完成条件

元記事は、Opus 5.5への指示から「よく考えて」「段階的に考えて」のような文を外すことも勧めている。これはすべてのAIに通じる万能なルールではなく、Opus 5.5が回答前に自分で思考量を調整するという説明に基づく助言だ。

私なら、「もっと深く考えて」と追いかける前に、完成をどう判定するかを言葉にする。画面の修正なら、見た目の好みだけでなく、幅の違う画面で崩れないこと、主要操作が動くこと、エラーが出ないことまで含められる。

ただし、条件を増やしすぎればよいわけでもない。実際に確かめられる条件に絞る。確認できなかった項目は、合格したことにせず、そのまま報告してもらう。

長い作業では、現在地を会話の外に残す

作業が何時間も続くと、最初の依頼や途中の判断が会話の奥へ流れていく。元記事は、入力が必要ない作業は続け、破壊的な操作の前には止まる条件を CLAUDE.md に書く例を示している。

同時に、対象、完了したこと、残り、判断待ち、検証結果を TASKS.md のようなファイルへ短く残す。会話が要約されても、そのファイルを見れば再開点が分かる。

会話が長くなり要約されても、TASKS.mdに完了・残り・判断待ちを残して再開する流れ

大きな調査や修正を分担するときも同じだ。担当を分けたこと自体を成果にせず、親役が各担当の根拠を読み、重複や矛盾を確かめてから一つの結論にする。

終わったら、報告より先に「何を待っているか」を見る

元記事は、長い作業が終わったら、まずAIが人に求めている判断や承認を読むよう勧めている。そのあとで、変更内容と検証結果を見る。コードなら差分レビューを別に頼み、調査なら「確認できなかったこと」も明示させる。

「テストしました」という一文だけでは完成を判定できない。どのテストが通ったか、目視で何を確かめたか、どこが未確認かまで分かれば、人が次の判断をしやすくなる。

私の作業なら、こう渡す

たとえば投球モーションの修正なら「大谷翔平のフォームに近づけて」だけでは終点が見えない。

依頼文の例: 24フレームを通して動きを確認し、接地・リリース・フォロースルーを重点的に直してください。目視と既存の検証方法の両方で確認し、問題があれば修正して再検証してください。完成時には、改善した箇所、確認した証拠、なお判断が必要な箇所を示してください。元のデータを消す操作と公開の前には止まってください。

この書き方なら、AIは途中の小さな判断を自分で進められる。一方で、フォームの良し悪しという人間の判断や、元データの削除、公開は勝手に越えない。

私が続けてきた「整理する → 作る → 検証する」という流れも、そのまま使える。変えるとしたら、最初の整理で完成条件まで決め、検証で見つかった問題を修正と再確認につなげることだ。

任せるために、先に境界を決める

依頼者が目的と停止条件を決め、AIが調査・作業・検証を進めて証拠を返す流れ

次の依頼では、まずこの五つを書く。

  1. 何を達成したいか。
  2. どこまでが対象か。
  3. 何をもって完成とするか。
  4. どの操作の前に止まるか。
  5. 最後にどんな証拠を見せてほしいか。

細かな手順を全部指定する必要はない。こちらが決めるべきなのは、仕事の目的と受け入れ基準だ。AIには、その範囲で調べ、作り、確かめ、必要なら直すところまで任せる。最後は人が証拠を見て判断する。

—

元記事:Addy Osmani「Getting the most out of Opus 5.5 in Claude and Claude Code」(2026年9月22日)。この記事は元記事を踏まえて自分の依頼の仕方を整理したもので、モデルの性能を独自に比較したものではありません。

コメントを残す