五つの会議記録を一つの週報にまとめるとは、一見単一に見えて実際には二段階あるタスクを指す。まず各会議の要点を個別に要約し、人がその要約に問題がないことを確認したうえで、それらを一つの週報に統合する。これは一般に理解されている「AIに週報を作ってもらう」とは異なる。多くの人は直感的にタスク全体を一回の呼び出しに投げ込み、Claudeが要約と統合を一気に済ませてくれると期待するが、このタスクの構造には本当に人の目による確認を必要とする中間地点がある。個別要約の段階で脱線した内容が紛れ込んだり、複数の会議が実は同じことを話していたと気づいたりすることがあり、この判断は要約を見て初めて下せるものであり、省略できない。
このやり方が必要とされるのは、一回の呼び出しで「何が本当の要点か」と「どの会議が同じことを話しているか」という二層の判断を同時に処理しなければならず、後者の答えは前者の結果を見て初めて分かるからだ。まだどの要約も見ていない段階で、Claudeに「二番目と四番目の会議は実は同じプロジェクトについて話しているので統合してください」とあらかじめ伝えることはできない。自分自身もまだそのことに気づいていないからだ。これこそ、週報の出力品質が不安定なことに初めて直面した人が、指示が十分正確でなかったと誤解しがちな理由である。問題は指示にあるのではなく、タスク自体が本来、順番に発生する二つの判断層に分かれている点にあり、それを一回の呼び出しに無理やり詰め込むことは、Claudeに中間情報が一切ない状態で二層の判断を同時にこなすよう求めることに等しい。
操作は二段階だ。第一に、五つの会議の逐語記録をClaudeに渡し、「各会議についてそれぞれ個別に要点の要約を作成してください。五つを分けて列挙し、統合しないでください」と明確に指示する。この段階では意図的に統合を求めず、統合の判断によって汚染されていない生の要約を先に手に入れることが目的だ。第二に、二、三分かけてその五つの要約を読み、特に三点を確認する。脱線した雑談を要点として書いている要約はないか、実は同じプロジェクトについて話していて統合すべき会議はどれか、そもそも上に報告する価値のある内容がない会議はないか。五つの要約を確認あるいは軽く修正したうえで、まとめてClaudeに渡し、二回目の指示として「これら確認済みの五つの要約を統合し、一つの週報にしてください」と伝える。二回の呼び出しの間に挟む人による確認こそ、この流れ全体の中で誤りが最終文書に持ち込まれるのを防ぐ本当の鍵となる動作である。
あなたにとって、この流れが本当に変えるのは「誤りに気づくタイミング」である。一気にやるやり方では、誤りに全く気づかないまま提出してしまうか、提出後に上司に指摘されて事後対応することになる。二段階に分けて間に一度確認を挟めば、誤りはまだ五つの要約のうちの一つに留まっている段階、最終文書に統合される前に食い止められ、修正コストははるかに低い。注意すべきは、この流れを踏む価値がある場面をどう判断するかだ。会議数が少なく、内容が単純で、要点が何かを既に自分で分かっている週は、そのまま一回で済ませればよく、流れのために流れを踏む必要はない。会議数が多く内容が互いに重なっている週や、この週報について自分が責任を持たなければならない週は、途中の二、三分の確認によって、上司の前で答えられずに困る事態を避けられる。これは十分に見合う投資だ。
金曜の午後、今週開かれた五つの会議の逐語記録が手元にあり、合わせて一万字近い。退勤前に上司へ提出する週報を作らなければならない。直感的なやり方は、五つの逐語記録すべてをClaudeに貼り付け、「これらの会議の要点をまとめて週報にして」と指示することだ。これは大抵何かしらの結果を出すが、実際に使ったことのある人なら分かるように、出来上がった週報はどこかおかしいことが多い。ある会議の脱線した雑談が要点として書き込まれていたり、二つの会議が同じプロジェクトについて話し合っていたのに、週報では二段落に分かれて重複しつつ矛盾していたりする。
こうした出力の問題に初めて直面したとき、多くの人は自分の指示が十分に正確でなかったと考え、プロンプトをもっと長くし、修飾語を増やそうとする（「本当に重要な要点だけを要約し、雑談は無視してください」）。この方向はたいてい効果が薄い。問題は指示の精度にあるのではなく、タスク自体に本来、中間地点が必要だからだ。まず五つの会議それぞれの要点を個別に要約し、その五つの要約に目を通して脱線した内容が紛れ込んでいないか、どの会議が実は同じことを話していたかを確認したうえで、初めて次の段階、つまり既にふるいにかけた要約を一つの週報に統合する作業へ進む。この中間地点はあってもなくてもよい飾りではなく、このタスクの構造上、本当に人の目による確認を必要とする節目である。
具体的なやり方は二段階だ。第一に、五つの会議の逐語記録をそれぞれ（あるいは一度にまとめて、ただし各会議の境界を明確に示して）Claudeに渡し、「各会議についてそれぞれ個別に要点の要約を作成してください。統合しないでください」と依頼する。この段階の成果物は五つの独立した要約であり、一つの週報ではない。第二に、二、三分かけてその五つの要約に目を通す。これがこの流れ全体の中で本当に自分の判断が必要な箇所だ。脱線した雑談を要点として扱っている要約はないか、実は同じプロジェクトについて話していて一緒にまとめるべき会議はどれか、そもそも上に報告する価値のある内容がない会議はないか。五つの要約を確認あるいは軽く修正したうえで、初めてそれらをまとめてClaudeに渡し、今度は「これら確認済みの五つの要約を統合し、一つの週報にしてください」と依頼する。
これは本質的に prompt chaining（プロンプトチェイニング）の実際の応用である。大きなタスクを複数の独立したプロンプトに分割し、ある呼び出しの出力を確認したうえで、次の呼び出しの入力とする。その価値は「分割する方が高度だから」ではなく、分割することで誤りが発生したその段階に留まり、最終的な週報まで持ち込まれて初めて気づくという事態を防げる点にある。すべてを一回の呼び出しで済ませると、元の一万字の記録を自分で逐語読んで誤りを探すか（それは自分でやり直すのと同じだ）、脱線した内容を要点として上司に提出してしまうリスクを負うか、そのどちらかになる。
すべての週報作成でこの流れを踏む価値があるわけではない。今週の会議が一つだけで、内容が単純で、要点が何かについて既に自分の中で答えが出ているなら、一回の呼び出しで通常十分であり、二段階に分けることはかえって、既に答えを知っている要約の確認に余計な時間をかけるだけになる。分ける価値があるのは、会議数が多い（三件以上）、内容が互いに重なっていたり突き合わせが必要だったりする、あるいはこの週報が上に提出され自分がその内容に責任を持つ必要がある場合だ。これらの条件に当てはまるほど、中間地点での確認の価値は高くなる。
五つの会議、一万字を一回の呼び出しで済ませれば、通常一、二分で結果が出て、時間の節約に見える。しかしその週報に脱線した内容や重複・矛盾する段落が混ざっていれば、上司との会議で聞かれて答えられなかったり、元の記録全体を改めて照合し直す時間をかけたりすることになり、その代償は中間で立ち止まる二、三分よりはるかに大きい。二段階に分けて間に素早い確認を挟むのは一見遅く見えるが、実際には誤りのコストを「週報を提出した後」から「提出する前」へ前倒ししているのであり、後者は常に前者より安く済む。