AI が変わっても、仕事はやり直しにならない。
AI を切り替えることは簡単です。仕事を再構築することは簡単ではありません。Epismo は結果、コンテキスト、レビューを一緒に保ち、次の人やモデルがそこから続きを進められるようにします。チームが繰り返し現れるパターンを見つけたら、それをプレイブックにし、次の案件を始めるために使えます。
はじめに
下書きはコピーした。でも、その背景にある判断はコピーしていない。
これは、AI を使った仕事でよくある引き継ぎです。あるモデルがローンチ告知の最初の下書きを書きます。チームはすでに、「すべての AI に対応している」とは書かないと決めています。その表現は、現在サポートしている連携の範囲を超えてしまうからです。誰かが文章を整えるために、下書きを2つ目のモデルに貼り付けます。2つ目のモデルは、求められた通りに動き、より強い表現を返します。
「チームが使うすべての AI に対応しています。」
2つ目のモデルが不注意だったわけではありません。その制約を受け取っていないのです。受け取ったのは一つの段落と、文章を改善する指示だけでした。下書きは移動しました。しかし、下書きの周りにある仕事は、最初のチャットやスレッド、あるいは誰かの頭の中に残りました。
次の10分間に何が起きるかは想像できます。新しいチャットを開き、すでに存在する仕事を説明し直す。古いスレッドから一文を探す。どれが最新バージョンなのかを確認する。モデルは速くても、ブリーフィングは速くありません。
この再構築を、私たちは re-briefing tax と呼びます。人、モデル、セッションが変わるときに、仕事が共有された場所を持っていなければ、これが当たり前になります。
AI は変わっても、仕事まで最初からやり直す必要はありません。
📖 TOC
持ち運べることと、続けられることは違う
一見すると、両方のツールから見られる場所に下書きを保存すればよさそうに思えます。それは役立ちます。しかし、それだけでは足りません。
この問題は、長い会話履歴を貼り付ける、スレッドをエクスポートする、次のモデル向けにより良いブリーフを書く、といったプロンプトの問題として扱われがちです。しかし、貼り付ける内容を増やしても、重要な問いには確実に答えられません。現在のバージョンはどれか。どの判断がまだ有効か。何がすでにレビューされたか。次に何をすべきか。
持ち運べるとは、別のツールで下書きを開けることです。続けられるとは、次の担当者が、その仕事が何であるか、なぜ今の形になっているか、何がすでに検討・指摘されたか、そして次に何をすべきかを理解できることです。
判断を伴わない保存済みの成果物は、過剰な主張へと「改善」されてしまうことがあります。別のチャットにあるレビューは、追いかけるべき2つ目の成果物になります。誰か一人の記憶にだけある次の一手は、別の人やモデルが仕事を引き継いだ瞬間に失われます。
この要求は、しばしば「メモリ」として語られます。つまり、前の会話を残してほしいということです。しかし、それだけでは、下書きと、そこに対する却下や指摘が別の場所に残ります。レビューで指摘された主張を、次のモデルが再び磨き上げてしまうかもしれません。指摘自体が、仕事と一緒に移動していないからです。
レビューも仕事と一緒に移動すべきだ
AI を使った仕事に必要なのは、ファイルではなくループです。
結果 → レビュー → 修正 → 判断 → 次の一手
ソフトウェアチームは、すでにこのパターンに依存しています。変更内容、その履歴、レビューコメントが同じ場所にあるからこそ、変更はレビュー可能になります。誰もパッチをメールで送り、あとからフィードバックが見つかることを期待しません。レビューする人は仕事を見て、書いた人は仕事とコメントを一緒に見返します。
AI を使うワークフローでは、次の担当者が別の人の場合も、別のモデルの場合もあります。ある AI が結果を書き、別の視点によるレビューが、根拠のない主張、弱い前提、未解決の問いを指摘する。別の AI や人がそれを修正し、人が最終的な判断を下すこともできます。
レビューが結果から離れると、このループは壊れ、チームは再び re-briefing tax を払うことになります。
ここに、もう一つの問題があります。仕事はツール間を移動できるだけでは不十分です。レビュー可能で、続けられる状態でなければなりません。保存された結果、その背景にあるコンテキスト、レビューが一緒に残っていることで、次の担当者はその3つすべてをもとに作業できます。
次のモデルに必要なのは、より長いプロンプトではない
Epismo では、案件 が一つの実際の仕事のための共有された場所になります。案件は別のチャットボットでも、すべてのセッションを投げ込む場所でもありません。案件には、次の担当者がそうでなければ再構築しなければならないものを残します。現在の結果、その背景にある判断、未解決の問い、レビュー、次の一手です。生のチャット履歴、ツール呼び出し、リトライ、ローカルファイルは、それを生み出したランタイムに残しておけます。
ローンチ告知の例に戻りましょう。
案件にはすでに、下書きとサポート対象の連携だけを記載するという判断があります。自動レビューを有効にすると、Epismo は保存された結果をレビューし、同じ案件に指摘を書きます。この主張は、そこに記録された連携の範囲よりも広すぎる、と。元の下書きを黙って書き換えることはありません。下書きは残り、レビューもその隣に残ります。
案件へのアクセス権を持つ人や接続済みの AI は、下書き、制約、指摘の3つすべてから仕事を続けられます。主張を修正し、改善された結果を次の担当者のために保存します。
モデルが急に賢くなったわけではありません。仕事と、その周りのレビューを受け取ったのです。
トランスクリプトは会話です。案件は仕事です。貼り付けは、再開ではありません。
まずは案件、プレイブックはその後。
このループを何度も繰り返すと、パターンが見えてきます。ローンチコピーには、公開前に必ず主張のレビューが必要かもしれません。リサーチブリーフでは、誰かが提案を書く前に情報源が必要かもしれません。下書きを始める前に、判断を記録すべきかもしれません。
その学びは、ある種類の仕事に再利用できるアプローチである プレイブック になります。案件は、今日の仕事を続けるためのものです。プレイブックは、チームが次の同種の仕事をより良く進めるためのものです。
チームがプレイブックを作ったところで、このサイクルは終わりません。同じような仕事が再び始まるとき、チームはそのプレイブックをもとに新しい案件を始められます。プレイブックは新しい案件に共有された方法を与え、新しい案件は、その実行で生まれる具体的な結果、判断、レビュー、次の一手を保持します。
実際の循環は次のようになります。
案件 → 実際の仕事からの学び → プレイブック → 新しい案件
すべての仕事を始める前に、方法を定義することが目的ではありません。有用な方法は、実際の仕事がどこで停滞したか、レビューが何を見つけたか、どの判断が繰り返し重要だったかをチームが見た後に、はっきりすることが多いからです。
方法から始めるのではなく、仕事から始めます。
まずは案件、プレイブックはその後。
仕事は、切り替えを越えて残るべきだ
モデルはこれからも変わります。チームはこれからも複数のモデルを組み合わせて使います。それこそが、複数の選択肢を持つ意味です。
ツールを変えるたびに、コンテキストを手作業で運ぶか、失うかを選ばなくてはならない状態であってはいけません。重要なのは、どのツールが会話を所有するかではありません。人や AI が変わったときにも、仕事が理解でき、レビューでき、続けられる状態であるかどうかです。
結果、コンテキスト、レビューが一緒に残れば、チームは仕事を移すコストが高いから一つのツールに留まるのではなく、次の仕事に合った強みを持つツールを選べます。
AI は変わっても、案件は残ります。
AI を切り替えても、仕事は残る。