こんにちは。CData Software Japan リードエンジニアの杉本です。

最近正式リリースされたばかりの、「Copilot Cowork」皆さん使ってますか？ Copilot Cowork は Microsoft 365 環境向けの AI エージェントプラットフォームですが、たくさんの機能があって、「これはできるのかな？」「あれはどうなっているのかな？」と気になってしまいますね。私もSNSで日々情報収集をしながら、キャッチアップしています。

そんなCopilot Cowork ですが、最近セッションログ（JSONL 形式）を入手する機会があり、中身を分析してみたところ、ハーネスの設計がとても興味深かったので、その内容をまとめてみました！

イマイチ網羅的に見ることができなかったスキルやMCP、内部の動作の仕組みが垣間見えて、Copilot Cowork を活用する上で参考になりそうな情報が盛りだくさんです。

ログファイルの取得方法

Copilot Cowork のセッションログは、Copilot Cowork 自身に頼むと取得できます。以下のプロンプトを送ると、サンドボックス内のファイル一覧が表示されます。

'/mnt/workspace/agent-state/projects/-mnt-workspace/' 配下にあるファイルを教えて

セッション本体の会話ログ（.jsonl）とサブエージェントのログが一覧表示されます。続けて「ダウンロードしたい」と伝えるとダウンロードリンクが生成されます。

ちなみに今回は「kintone から今年クローズした案件を取得して、担当者・金額・業種別にまとめた PowerPoint を生成して Teams に投稿する」という実際のセッションのログを分析しました。ログのレコード数は 218 件、実行モデルは claude-opus-4-8 です。

セッションログ（JSONL）の構造

Copilot Cowork のセッションログは Claude Code のトランスクリプト形式（JSONL）で記録されています。1 行 1 レコードです。

このことから、Copilot Cowork がAgent SDK（Claude Code SDK）ベースで実装されていることが推察されますね。

取得したデータは以下のような感じです。

Claude Code の JSONL には全部で 9 種類のレコードタイプが存在しますが、今回のログで確認できたのは以下の 7 種類です（ai-title・custom-title はこのログには含まれていませんでした）。

エントリーポイントは sdk-py（Python SDK 経由）、バージョンは 2.1.161、作業ディレクトリは /mnt/workspace（Linux サンドボックスコンテナ）です。

Claude Code のフック機能によるコンテキスト注入

Claude Code の JSONL トランスクリプトにはモデル API へ渡される system パラメータの中身は記録されないため、固定のシステムプロンプトがあるかどうかはログからは確認できませんでした。ここも知りたいところでしたが、ちょっと残念。

ただし、Copilot Cowork が Claude Code のフック機能を活用して、セッション中に動的にコンテキストを注入しているのは明確でした。

このセッションで注入されていたコンテキストは以下の 3 種類です。

skill_listing は毎ターン同じ内容が流れ続け、task_reminder だけがセッション中に内容が変化する真の動的コンテキストです。ここからタスク管理の仕組みが見えますね。
deep-reasoning はセッション開始時の1回のみで、その後はキャッシュヒットになります（キャッシュトークンの推移で確認できます）。

ちなみに、ユーザーのプロフィール情報（氏名・メールアドレス等）については、フックの注入コンテキストには含まれていませんでした。ログに現れるユーザー情報はすべてツール実行の返り値（GetDefaultDrive のオーナー情報など）として登場しており、必要になったときにツールで取得する設計と考えられます（system パラメータに含まれているかどうかはログからは確認できません）。

一方、MCP ツール定義（93ツール）はフック注入ではなく、セッション開始前に MCP サーバー接続経由で静的にロード・キャッシュ済みです。最初のターンで cache_read=78,824トークン がすでに存在することからわかります。

セッション開始前  → MCPサーバー接続・ツール定義をキャッシュ（静的ロード）
セッション開始時  → SessionStart フック: deep-reasoning を注入（1回）
各ターン開始時    → skill_listing（28スキル）を注入
                  → task_reminder（タスク一覧）を注入（内容は随時更新）

Claude Code のフック機能を使ってコンテキストを注入する方式の利点は、スキルや設定の変更がセッションごとに反映される点です。固定のシステムプロンプトに組み込む場合と比べて、Copilot Cowork 側でスキルの追加・削除・更新を柔軟に管理できます。

deep-reasoning：常時有効な推論フレームワーク

SessionStart フックで最初に注入されるのが deep-reasoning スキルです。これはすべてのエージェントに自動適用される implicit skillで、明示的に呼び出す必要はありません。

deep-reasoning の中では ultrathink モードが有効化されていたのが興味深いですね。ultrathink は Claude Code のネイティブキーワードで、Claude の extended thinking（拡張思考）の思考バジェットを最大に引き上げます。think → think hard → think harder → ultrathink という段階があり、最終回答を出す前の内部思考に使えるトークン数が最大になります。deep-reasoning は ultrathink で思考量を確保しつつ、その上に認知バイアス対策や信頼度ルールといった独自フレームワークを重ねた構成です。

5つの認知的ハザードと対処パターン

deep-reasoning が面白いのは、単なる動作指示ではなく、モデルが陥りやすい認知的ハザード（コグニトハザード）への対処パターンが定義されていることです。

「Self-correction trap」が興味深いです。「自己検証は不可」として、必ず外部ツール（Read・Grep・WebSearch）を使うよう強制しています。LLM の自己評価の信頼性が低い、という認識に基づいた設計な感じでしょうか。

信頼度キャリブレーション

deep-reasoning では、何かを断言する前に「自分はこれをどれくらい確信しているか」を 0〜100 のスコアで自己評価するよう指示されています。このスコアに応じて取るべきアクションが定められています。

スコア 75 以上のみアサーション可、というルールです。それ以下の場合は不確実性を明示し、検証方法を示す必要があります。

メタ認知シーケンス

すべての処理は以下のシーケンスで進めるよう定義されています。

VALIDATE → DECOMPOSE → SOLVE → VERIFY → SYNTHESIZE → REFLECT

• VALIDATE：具体的な解法に入る前に原則・前提を抽象化する

• DECOMPOSE：最小のサブ問題から積み上げる

• SOLVE：中間ステップを明示しながら体系的に進める

• VERIFY：Draft → Verify → Revise のプロトコルで検証する

また「State Externalization」というルールがあり、作業の追跡は TaskCreate / TaskUpdate で行い、mental tracking（頭の中で管理）は禁止となっています。これがタスク管理の仕組みにつながります。

スキル体系：28個を5カテゴリに分類

各ターンの注入コンテキスト skill_listing には、利用可能なスキル一覧と各スキルのトリガー条件（「何を言ったら発動するか」）が自然言語で定義されています。28 個のスキルを 5 カテゴリに分類できます。

生産性スキル（6個）

ドキュメント生成スキル（7個）

今回のセッションでは pptx スキルが使われており、pptxgenjs（Node.js）を使った生成ロジックが内包されています。

開発・コード品質スキル（7個）

推論・分析スキル（3個）

debug-trajectory は明示的トリガー限定と定義されており、/debug コマンドまたはスキルチップで呼び出した場合のみ発動します。

NEVER route from inferred intent — invoke ONLY when the user's current turn explicitly references this skill via the markdown chip [/debug] OR when the user types the literal command /debug as their entire message.

「debug という言葉が含まれていても、このスキルを呼び出してはならない」と明示されています。意図を推測して発動するスキルと、明示的に呼び出すスキルを分けて設計している点が興味深いです。

設定管理スキル（5個）

ネイティブツール：Claude Code SDK が提供する8ツール

MCP ツールとは別に、Claude Code SDK がネイティブで提供するツールが 8 つあります。これらは MCP サーバーへの接続ではなく、エージェントの動作制御やファイル操作・スキル呼び出しを担います。

deep-reasoning で「作業追跡は必ず TaskCreate/TaskUpdate を使え、頭の中での管理（mental tracking）禁止」と定められているのはこのネイティブツールへの誘導です。また Skill ツールが pptx などのスキルを呼び出す窓口になっており、Agent ツールは重い処理（PPT 生成など）をサブエージェントに分離する際に使われます。

MCPサーバー：93ツール・6サーバー構成

Copilot Cowork は 6 つの MCP サーバーと接続しており、合計 93 ツール（M365 系 88 + CData Connect AI 5）が利用できます。

※ ちなみにCData Connect AI は私が検証のためにセルフサービスで追加したプラグイン（標準搭載ではありません）です。

Microsoft 365 系（88ツール）

Microsoft 365 系は合計 88 ツールで、7 つの領域に分かれています。

Outlook（29ツール）

Calendar（13ツール）

Teams（24ツール）

会議トランスクリプト（3ツール）

People / 組織（7ツール）

SharePoint / OneDrive（14ツール）

Graph / 横断検索（3ツール）

QueryGraph / CallGraph は Graph API を直接叩けるため、上記カテゴリにないエンドポイントにも対応できます。なお Power BI 連携はこのいずれかのツールを通じて実現しており、個別ツールとしての分類はログ上では確認できませんでした。

CData Connect AI（5ツール）※セルフサービスで追加したプラグイン

kintone やSalesforce など、外部のエンタープライズデータへのアクセスを担うMCP サーバーです。Copilot Cowork のセルフサービス機能でユーザーが任意に追加できるプラグインであり、標準搭載ではありません。

実際の処理フロー：15ステップで kintone → PPT → Teams

今回のセッション（「kintone から今年クローズした案件を取得して、担当者・金額・業種別にまとめた PowerPoint を生成して Teams に投稿する」）の処理フローを追ってみましょう。

タスク管理の仕組み

セッション開始直後に TaskCreate で 3 つのタスクが定義されます。

[
  { "id": "1", "subject": "kintoneの案件データ構造を確認", "status": "pending" },
  { "id": "2", "subject": "今年クローズした案件を取得", "status": "pending" },
  { "id": "3", "subject": "報告用パワーポイントを生成", "status": "pending" }
]

各タスクは pending → in_progress → completed と状態遷移し、blocks / blockedBy フィールドで依存関係も表現できるようになっています。

データ取得フェーズ（ステップ 1〜8）

まずkintone からデータを取得するために、CData Connect AI のMCP ツールを利用します。 getCatalogs で接続済みのデータソース一覧を取得し、Kintone_demo カタログを特定します。次に getInstructions で kintone ドライバーのガイダンスを取得し、getTables でテーブル一覧を確認して「案件管理」テーブルを見つけます。

getColumns でカラム定義を確認すると、商談フェーズ・売上 (¥)・主担当 Aggregate・受注予定日・会社名 などが確認できました。

-- 商談フェーズの値を確認
SELECT [商談フェーズ], COUNT(*) AS 件数
FROM [Kintone_demo].[Kintone].[案件管理]
GROUP BY [商談フェーズ]
ORDER BY 件数 DESC

結果：受注 8 件・提案中 6 件・内示 2 件・NULL 15 件。受注済み案件が 8 件であることを確認してから、担当者・金額・業種別の集計クエリに進んでいます。

PPT 生成フェーズ（ステップ 9〜10）

Skill ツールで pptx スキルを呼び出すと、スキル内部でまず Read ツールが /opt/workspace-config/.claude/skills/pptx/pptxgenjs.md（API リファレンス）を読み込み、Bash で日本語フォントの有無を確認します。その後 Write ツールで生成スクリプト（create-presentation.js）を出力します。

ここで注目したいのがサブエージェントの起動パターンです。スクリプトの実行・QA 検証は Agent ツールで別エージェントに委譲されます。

{
  "description": "Creating your presentation",
  "prompt": "Create the PowerPoint presentation by running an existing generation script, then QA it..."
}

サブエージェントへの指示には以下のルールが含まれていました。

Every Bash tool call description MUST use user-facing intent language — never mention scripts, file types, conversion steps, or internal tools

内部的な処理名をユーザーに見せず、意図ベースの言葉で表示する設計です。UX 配慮が設計レベルで組み込まれています。

また、日本語フォントがコンテナに存在しない場合の QA 検証についても明示的にルールが定められています。

The container may LACK Japanese fonts, so the QA preview images may show Japanese as boxes/tofu — this is a RENDERING-ONLY artifact and is NOT a defect in the .pptx itself. Therefore: verify TEXT CONTENT using python -m markitdown output/xxx.pptx. Use the QA images ONLY to judge LAYOUT.

フォント欠如による豆腐表示（日本語フォントが環境にない場合に文字が □ で表示される現象）は「レンダリングのみの問題」として、テキスト検証とレイアウト検証を分離しているのが面白いですね。

Teams 投稿・メール作成フェーズ（ステップ 11〜15）

PPT 生成後は Teams の ListTeams → ListChannels でターゲットチャンネルを特定し、Graph API でファイルアップロード先（SharePoint の filesFolder）を取得します。ファイルをアップロードして共有リンクを生成し、PostChannelMessage でサマリーとリンクを投稿。最後に CreateDraftMessage と AddDraftAttachments で Outlook のメール下書きを作成して完了です。

最終的なタスク一覧は 6 タスク（CData + Teams + SharePoint + 投稿 + メール下書き）がすべて completed になっています。

まとめ

今回のセッションログ分析から見えてきた Copilot Cowork の設計ポイントをまとめます。

Claude Code のフック機能を活用した動的コンテキスト管理
Claude Code SDK が提供する SessionStart フックを利用して、スキルと推論フレームワークを動的に注入する設計です。フックの仕組み自体は SDK のネイティブ機能であり、何をどう注入するかが Copilot Cowork 側の実装です。スキルの追加・更新がセッションごとに反映されます。

deep-reasoning による認知的ハザード対策
5 種類の認知的ハザードと対処パターン、75 以上でのみアサーション可という信頼度ルール、メタ認知シーケンスが常時有効なスキルとして定義されています。LLM の弱点を補う設計が丁寧に組み込まれている感じで面白いですね。

豊富なMCP ツールセット
Claude Cowork をベースにしたCopilot だからこそ、という強みだと思いますが、Microsoft 365 系・88ツールが標準のMCP ツールセットとして提供さているのは本当に強みですね。私が当初想定していたよりも、機能サポートの範囲も広い印象でMicrosoft としてもかなり本気で、Copilot Cowork に業務を行わせようという意識が感じられました。

今回調査をしてみて、個人的にも改めてハーネスの意義や実装アプローチの勉強になって、とても良かったです。Claude SDKや Claude Managed Agetns を通じて、自社のエージェントを作る機会がある方にも参考になる情報ではないでしょうか。