Copilot Cowork の内側を覗いてみた ハーネスの設計はこうなっている
本記事はCDataが提供する「CData Software Blog」に掲載された「Copilot Cowork の内側を覗いてみた：セッションログから読み解く AI エージェントハーネス（コンテキスト・スキル・MCP）の設計」を再編集したものです。
こんにちは。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 はこのログには含まれていませんでした）。
| タイプ | 今回の会話での件数 | 内容 |
| assistant | 104 | モデルの応答・ツール呼び出し |
| user | 61 | ユーザー入力・ツール実行結果 |
| queue-operation | 20 | enqueue / dequeue 操作 |
| attachment | 10 | フックの実行結果・コンテキスト注入 |
| last-prompt | 13 | 直近のユーザープロンプト |
| mode | 5 | 実行モード（normal） |
| system | 5 | フック完了サマリー |
エントリーポイントは sdk-py（Python SDK 経由）、バージョンは 2.1.161、作業ディレクトリは /mnt/workspace（Linux サンドボックスコンテナ）です。
Claude Code のフック機能によるコンテキスト注入
Claude Code の JSONL トランスクリプトにはモデル API へ渡される system パラメータの中身は記録されないため、固定のシステムプロンプトがあるかどうかはログからは確認できませんでした。ここも知りたいところでしたが、ちょっと残念。
ただし、Copilot Cowork が Claude Code のフック機能を活用して、セッション中に動的にコンテキストを注入しているのは明確でした。
このセッションで注入されていたコンテキストは以下の 3 種類です。
| 種類 | タイプ | タイミング | 内容 |
| deep-reasoning | hook_success | セッション開始時に1回 | 推論フレームワーク全文（約6,400文字） |
| skill_listing | スキル一覧 | 毎ターン | 全28スキルの名前＋トリガー条件文（約12,700文字） |
| task_reminder | タスク一覧 | 毎ターン（内容は随時更新） | その時点のタスクリスト（JSON） |
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 が面白いのは、単なる動作指示ではなく、モデルが陥りやすい認知的ハザード（コグニトハザード）への対処パターンが定義されていることです。
| ハザード | 検出条件 | 対処 |
| Inherited certainty | ユーザーの主張をそのまま受け入れようとしている | 仮説として扱い、ツールで外部検証する |
| Self-correction trap | 「推論を確認しよう」と言いかけている | 自己検証は不可。Read / Grep / WebSearch を使う |
| Premature switching | 現アプローチが遅いが失敗していない | 2 回以上試みてから切り替える |
| Confirmation bias | 証拠がすべて初期仮説を支持している | 批判・問題点を能動的に検索する |
| Hasty commitment | 最初に見つけたアプローチに飛びつこうとしている | 代替案を検討してからコミットする |
「Self-correction trap」が興味深いです。「自己検証は不可」として、必ず外部ツール（Read・Grep・WebSearch）を使うよう強制しています。LLM の自己評価の信頼性が低い、という認識に基づいた設計な感じでしょうか。
信頼度キャリブレーション
deep-reasoning では、何かを断言する前に「自分はこれをどれくらい確信しているか」を 0〜100 のスコアで自己評価するよう指示されています。このスコアに応じて取るべきアクションが定められています。
| スコア | 意味 | アクション |
| 0–24 | 不確実 | 明示的に述べ、検証方法を特定する |
| 25–49 | 可能性あり | 不確実性を注記してから進む |
| 50–74 | 可能性高い | 主要な主張を検証する |
| 75+ | 検証済み | 自信を持って断言する |
スコア 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個）
| スキル名 | トリガー例 | 概要 |
| calendar-management | 「カレンダーを整理して」「会議が多すぎる」 | スケジュール管理・フォーカス時間防衛・会議トリアージ |
| daily-briefing | 「今日のブリーフィング」「今日の予定は？」 | カレンダー・メール・Teams を集約した優先度付き日次概要 |
| meeting-intel | 「会議を要約して」「アクションアイテムを抽出して」 | 会議ブリーフ・議事録・参加者コンテキスト提供 |
| schedule-meeting | 「会議をスケジュールして」「空き時間を探して」 | 会議スケジューリング・空き時間検索・会議室予約・リスケ |
| stakeholder-comms | 「経営層向けに報告して」「チームにアナウンスして」 | 読者に応じた経営層更新・チームアナウンス・リスクエスカレーション等の文書生成 |
| deep-research | 「詳しく調べて」「ファクトチェックして」 | 出典付きの深掘り調査・ファクトチェック |
ドキュメント生成スキル（7個）
| スキル名 | 出力形式 | 概要 |
| docx | Word (.docx) | レポート・SOP・提案書・議事録など。TOC・追跡変更・コメント対応 |
| pptx | PowerPoint (.pptx)プレゼン・ピッチデック。pptxgenjs + QAワークフロー | |
| xlsx | Excel (.xlsx) | スプレッドシート・数式・チャート・CSV など。LibreOffice で数式再計算も対応 |
| 生成・結合・分割・OCR・フォーム入力 | ||
| html | HTML | スタンドアロン HTML ページ・レポート・メール用 HTML（base64 画像埋め込み対応） |
| render-ui | Adaptive Card | 構造化データ・画像 URL をダッシュボード／グラフ／テーブルのカード形式でレンダリング |
| 画像生成 | PNG / 画像 | テキストから画像・アイコン・図を生成・編集 |
今回のセッションでは pptx スキルが使われており、pptxgenjs（Node.js）を使った生成ロジックが内包されています。
開発・コード品質スキル（7個）
| スキル名 | 概要 |
| verify | コード動作検証 |
| code-review | コードレビュー |
| simplify | コード簡略化・リファクタリング |
| run | アプリ起動・実行確認 |
| init | プロジェクト初期化 |
| review | PRレビュー |
| security-review | セキュリティレビュー |
推論・分析スキル（3個）
| スキル名 | 概要 |
| deep-reasoning | 前述の常時有効な推論フレームワーク（implicit skill） |
| claude-api | Claude API 仕様参照 |
| debug-trajectory | セッショントランスクリプトを HTML で可視化（明示的トリガー限定） |
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個）
| スキル名 | 概要 |
| update-config | settings.json による設定変更・フック管理 |
| keybindings-help | キーバインドカスタマイズ |
| skills | スキル管理 |
| loop | 繰り返し実行 |
| fewer-permission-prompts | 権限プロンプト削減 |
ネイティブツール：Claude Code SDK が提供する8ツール
MCP ツールとは別に、Claude Code SDK がネイティブで提供するツールが 8 つあります。これらは MCP サーバーへの接続ではなく、エージェントの動作制御やファイル操作・スキル呼び出しを担います。
| ツール名 | 説明 |
| TaskCreate | タスクを作成（subject・description・activeForm） |
| TaskUpdate | タスクのステータスを更新（pending / in_progress / completed） |
| Bash | シェルコマンドを実行 |
| Read | ファイルを読み込む |
| Write | ファイルを書き込む |
| Skill | スキルを呼び出す |
| Agent | サブエージェントを起動（description・prompt） |
| Glob | ファイルパターンマッチ検索 |
deep-reasoning で「作業追跡は必ず TaskCreate/TaskUpdate を使え、頭の中での管理（mental tracking）禁止」と定められているのはこのネイティブツールへの誘導です。また Skill ツールが pptx などのスキルを呼び出す窓口になっており、Agent ツールは重い処理（PPT 生成など）をサブエージェントに分離する際に使われます。
MCPサーバー：93ツール・6サーバー構成
Copilot Cowork は 6 つの MCP サーバーと接続しており、合計 93 ツール（M365 系 88 + CData Connect AI 5）が利用できます。
| サーバー | ツール数 | 概要 |
| Outlook | 29 | メール送受信・下書き・フォルダ・ルール・自動応答 |
| Teams | 24 | チャット・チャネル・メンバー管理・メッセージ投稿 |
| SharePoint / OneDrive | 14 | ファイル・フォルダ・サイト・リスト操作 |
| Calendar | 13 | 予定管理・空き時間検索・会議室予約 |
| People / 組織 | 7 | 人物検索・プロフィール・組織ツリー |
| Graph / 横断検索 | 3 | M365 横断検索・Graph API 直接アクセス |
| 会議トランスクリプト | 3 | 文字起こし取得・要約 |
| CData Connect AI ※ | 8 | 80以上のデータソースへの SQL アクセス |
※ ちなみにCData Connect AI は私が検証のためにセルフサービスで追加したプラグイン（標準搭載ではありません）です。
Microsoft 365 系（88ツール）
Microsoft 365 系は合計 88 ツールで、7 つの領域に分かれています。
Outlook（29ツール）
| ツール名 | 機能 |
| ListMessages | 受信トレイ／フォルダのメール一覧（送信者・日付・添付・未読等で絞込） |
| GetMessage | メール本文・添付の全文取得 |
| SendEmailWithAttachments | メール作成・即時送信（添付対応） |
| CreateDraftMessage | 新規メールの下書き作成 |
| CreateReplyDraft | 返信の下書き作成 |
| CreateReplyAllDraft | 全員返信の下書き作成 |
| UpdateDraft | 下書きの宛先・件名・本文の更新 |
| SendDraftMessage | 既存の下書きを送信 |
| AddDraftAttachments | 下書きへの添付追加 |
| UploadAttachment | 添付アップロード（3MB以下） |
| UploadLargeAttachment | 大容量添付アップロード（3〜150MB） |
| DeleteAttachment | 下書きの添付削除 |
| ReplyToMessage | 送信者へ返信（即時） |
| ReplyAllToMessage | 全員返信（即時） |
| ForwardMessage | メール転送（即時） |
| MoveMessage | メールを別フォルダへ移動 |
| DeleteMessage | メール削除（削除済みアイテムへ） |
| FlagEmail | フォローアップフラグの設定／解除 |
| UpdateMessage | 既読・重要度・分類などの更新 |
| ListMailFolders | メールフォルダ一覧 |
| GetMailFolder | フォルダ詳細取得 |
| CreateMailFolder | メールフォルダ作成 |
| ListMailRules | 受信ルール一覧 |
| CreateMailRule | 受信ルール作成 |
| UpdateMailRule | 受信ルール更新 |
| DeleteMailRule | 受信ルール削除 |
| GetAutoReplySettings | 自動応答（不在通知）設定の取得 |
| SetAutoReply | 自動応答の有効化・設定 |
| DisableAutoReply | 自動応答の無効化 |
Calendar（13ツール）
| ツール名 | 機能 |
| ListCalendarView | 期間指定の予定一覧（定期予定を個別展開） |
| ListEvents | 予定一覧（定期はマスター単位） |
| CreateEvent | 予定の新規作成 |
| UpdateEvent | 予定の変更（出席者追加・リスケ等） |
| DeleteEventById | 予定の削除 |
| AcceptEvent | 招待の承諾 |
| DeclineEvent | 招待の辞退 |
| TentativelyAcceptEvent | 仮承諾 |
| CancelEvent | 自分が主催する予定のキャンセル通知 |
| ForwardEvent | 予定の転送（FYI共有） |
| FindMeetingTimes | 出席者の空き時間候補の検索 |
| GetRooms | 会議室一覧の取得 |
| GetUserDateAndTimeZoneSettings | タイムゾーン・勤務時間設定の取得 |
Teams（24ツール）
| ツール名 | 機能 |
| ListTeams | 参加チーム一覧 |
| GetTeam | チーム詳細取得 |
| ListChannels | チャネル一覧 |
| GetChannel | チャネル詳細取得 |
| CreateChannel | チャネル作成 |
| CreatePrivateChannel | プライベートチャネル作成 |
| UpdateChannel | チャネル名・説明の更新 |
| ListChannelMembers | チャネルのメンバー一覧 |
| AddChannelMember | チャネルへメンバー追加 |
| UpdateChannelMember | メンバーの役割変更 |
| ListChannelMessages | チャネルのメッセージ一覧 |
| PostChannelMessage | チャネルへ投稿 |
| ReplyToChannelMessage | チャネル投稿への返信 |
| ListChats | チャット一覧（未読・相手で絞込） |
| GetChat | チャット詳細取得 |
| CreateChat | チャット作成 |
| UpdateChat | チャットのトピック変更 |
| AddChatMember | チャットへメンバー追加 |
| ListChatMembers | チャットのメンバー一覧 |
| ListChatMessages | チャットのメッセージ一覧 |
| GetChatMessage | チャットの特定メッセージ取得 |
| PostMessage | チャットへメッセージ送信（宛先名で自動作成） |
| UpdateChatMessage | チャットメッセージの編集 |
| DeleteChatMessage | チャットメッセージの削除 |
会議トランスクリプト（3ツール）
| ツール名 | 機能 |
| GetMyRecentTranscripts | 期間内の直近の会議文字起こしを一括取得 |
| ListMeetingTranscripts | 特定会議の文字起こし一覧 |
| GetMeetingTranscript | 文字起こし本文（話者・タイムスタンプ付）取得 |
People / 組織（7ツール）
| ツール名 | 機能 |
| GetMyDetails | 自分のプロフィール取得 |
| GetUserDetails | 特定ユーザーのプロフィール取得 |
| GetMultipleUsersDetails | 複数ユーザーのプロフィール一括取得 |
| SearchPeople | 人物検索（氏名・部署・役職・拠点等） |
| GetManagerDetails | 上司情報の取得 |
| GetDirectReportsDetails | 直属の部下一覧 |
| GetOrgTree | 組織ツリー（配下全体）の取得 |
SharePoint / OneDrive（14ツール）
| ツール名 | 機能 |
| GetDefaultDrive | 個人OneDrive／サイト既定ライブラリの取得 |
| ListDrives | サイトのドキュメントライブラリ一覧 |
| GetDriveChildren | フォルダ内のファイル・フォルダ一覧 |
| GetDriveItem | ファイル／フォルダのメタデータ取得 |
| ReadFileContent | ファイル内容の読み取り |
| SearchDrive | ドライブ内のファイル検索 |
| CreateFolder | フォルダ作成 |
| GetSite | SharePointサイトの取得 |
| SearchSites | サイト検索 |
| ListSubsites | サブサイト一覧 |
| ListLists | SharePointリスト一覧 |
| ListListColumns | リストの列（項目）一覧 |
| ListListItems | リストアイテム一覧 |
| GetOrgTemplateLibrary | 組織のブランドテンプレートライブラリ取得 |
Graph / 横断検索（3ツール）
| ツール名 | 機能 |
| SearchM365 | ファイル・メール・Teams・予定・Power BI 等の横断検索 |
| QueryGraph | Microsoft Graph への読み取り（GET）アクセス |
| CallGraph | Microsoft Graph への書き込み（POST/PUT/PATCH）アクセス |
QueryGraph / CallGraph は Graph API を直接叩けるため、上記カテゴリにないエンドポイントにも対応できます。なお Power BI 連携はこのいずれかのツールを通じて実現しており、個別ツールとしての分類はログ上では確認できませんでした。
CData Connect AI（5ツール）※セルフサービスで追加したプラグイン
kintone やSalesforce など、外部のエンタープライズデータへのアクセスを担うMCP サーバーです。Copilot Cowork のセルフサービス機能でユーザーが任意に追加できるプラグインであり、標準搭載ではありません。
| ツール名 | 説明 |
| getCatalogs | 利用可能なコネクション一覧を取得 |
| getSchemas | 特定カタログのデータベーススキーマを取得 |
| getTables | 特定カタログ・スキーマのテーブル一覧を取得 |
| getColumns | 特定テーブルの利用可能なカラム一覧を取得 |
| queryData | 接続済みデータソースに SQL クエリを実行し結果を取得 |
| getProcedures | 特定カタログ・スキーマのストアドプロシージャ一覧を取得 |
| getProcedureParameters | ストアドプロシージャのパラメータメタデータを取得 |
| executeProcedure | ストアドプロシージャを実行 |
実際の処理フロー：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
| 処理 | description（表示テキスト） |
| スライド生成 | "Building your slides" |
| エラー後再生成 | "Rebuilding your slides" |
| QA 検証 | "Checking the presentation for errors" |
| 修正適用 | "Fixing [specific issue]" |
| 後処理 | "Finalizing the presentation" |
内部的な処理名をユーザーに見せず、意図ベースの言葉で表示する設計です。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 を通じて、自社のエージェントを作る機会がある方にも参考になる情報ではないでしょうか。
本記事はアフィリエイトプログラムによる収益を得ている場合があります