security

Codex 互換性に関する注記：

• Codex でリポジトリのスキルを呼び出すには、$skill-name を使用してください。このミラー版では、従来の Claude の /skill-name 参照を書き換えています。
• タスクトラッカーに関する必須事項：ワークフローまたはスキルの手順を実行する前に、すべての手順のタスク追跡を作成または更新し、進捗が変わるたびに同期してください。
• ユーザーへの質問を促す指示がある場合は、Codex でユーザーに直接質問してください。
• Claude 固有のモード切り替え指示がある場合は無視してください。
• 厳格な実行ルール：ユーザーがスキルを明示的に呼び出した場合は、そのスキルのプロトコルを記載どおりに実行してください。
• サブエージェントの使用許可：スキルがユーザーによって呼び出された場合、または AI によって検出された場合に、そのプロトコルでサブエージェントが必要とされるなら、そのスキルの有効化によって、そのタスクに必要な spawn_agent サブエージェントの使用が許可されます。
• ユーザーが事前に逸脱を明示的に承認しない限り、手順を省略、並べ替え、統合しないでください。
• ワークフローのスキルでは、記載された各子スキルの手順を明示的に実行し、各手順の証跡を報告してください。
• 必須の手順またはツールをこの環境で実行できない場合は、適応する前に停止してユーザーに確認してください。

Codex のプロジェクト参照資料の読み込み（フックなし）

Codex では、Claude のフックによるドキュメントの自動挿入は行われません。 コーディング、計画、デバッグ、テスト、レビューを行う際は、このルーティングに従ってプロジェクトのドキュメントを明示的に開いてください。

必ず読むもの：

• docs/project-config.json（プロジェクト固有のパス、コマンド、モジュール、ワークフロー／テストの設定）
• docs/project-reference/docs-index-reference.md（docs/project-reference/* の全カタログへのルート）
• docs/project-reference/lessons.md（常に適用されるガードレールとアンチパターン）

状況に応じて読むドキュメント：

• バックエンド／CQRS／API／ドメイン／エンティティの変更：backend-patterns-reference.md、domain-entities-reference.md、project-structure-reference.md
• フロントエンド／UI／スタイル／デザインシステム：frontend-patterns-reference.md、scss-styling-guide.md、design-system/README.md
• 仕様／テストケースの計画または TC マッピング：feature-docs-reference.md
• 統合テストの実装／レビュー：integration-test-reference.md
• E2E テストの実装／レビュー：e2e-test-reference.md
• コードレビュー／監査：code-review-rules.md と、変更対象ファイルに応じた上記のドメインドキュメント

ドキュメントをむやみにすべて読まないでください。まず docs-index-reference.md を起点とし、タスクに関連するファイルのみを開いてください。

[BLOCKING] スキルの手順は宣言された順序で実行してください。ユーザーが明示的に承認しない限り、手順を省略、並べ替え、統合してはなりません。 [BLOCKING] 各手順またはサブスキルの呼び出しの前にタスク追跡を更新し、その手順の開始時に in_progress、終了時に completed に設定してください。 [BLOCKING] 完了またはスキップした手順には、必ず簡潔な証跡または明示的なスキップ理由を記載してください。 [BLOCKING] Task ツールを利用できない場合は、同じステータス遷移を伴う同等の手順ごとの計画トラッカーを作成し、維持してください。

概要

目標： OWASP Top 10 とプロジェクトの認可パターンに照らしてセキュリティレビューを実施します。

ワークフロー：

1. スコープ — セキュリティ上重要なコード領域を特定します
2. 監査 — OWASP のカテゴリとプラットフォームのセキュリティパターンに照らしてレビューします
3. 報告 — 重大度と修正方法を含めて検出事項を記録します

主なルール：

• 分析の姿勢：推測ではなく、体系的にレビューします
• バックエンドとフロントエンドの両方の攻撃対象領域を確認します
• プロジェクトの認可属性とエンティティレベルのアクセス式を使用してください（docs/project-reference/backend-patterns-reference.md を参照）

$ARGUMENTS

分析の姿勢（絶対遵守）

懐疑的な姿勢を保ち、批判的思考と順序立てた思考を適用してください。すべての主張には追跡可能な証拠が必要です。確信度をパーセンテージで示してください（アイデアは 80％を超える必要があります）。

• 実際の実装を読んでセキュリティを検証してください。コードが安全だと最初から決めつけないでください
• 脆弱性の指摘にはすべて、file:line 形式の証拠を含めてください
• コードを追跡して脆弱性を証明できない場合は、「潜在的なリスクであり、確認されていません」と明記してください
• 前提を問い直してください。「これは実際に悪用可能なのか？」→ 入力経路を追跡して確認してください
• 網羅性を検証してください。「ほかにも攻撃ベクトルはないか？」→ すべての入力境界を確認してください
• 証拠なしに「安全そう」とは言わないでください。検証した内容とその方法を明記してください

arch-security-review スキルを有効にし、そのワークフローに従ってください。

重要：セキュリティに関する指摘を提示してください。修正を実装する前に、ユーザーの明示的な承認を待ってください。

サブエージェントの種類の上書き

必須： セキュリティレビューの Round 2 では、code-reviewer ではなく security-auditor サブエージェントを起動してください。 理由： security-auditor には、code-reviewer にない OWASP 専用プロトコル、認証フロー分析、インジェクションリスクの追跡、依存関係の CVE チェック、マイクロサービス境界のセキュリティに関するコンテキストがあります。

再帰的な品質ループ

1. Round 1： メインエージェント（または arch-security-review スキル）が分析を実施し、指摘レポートの草案を作成します
2. Round 2： 新しい security-auditor サブエージェント（agent_type: "security-auditor"）を起動します。Round 1 の記憶は一切持たせません。プロンプトには OWASP Top 10 チェックリスト、認証フロー、インジェクションリスク、依存関係の CVE、マイクロサービス境界のセキュリティを含めてください
3. 問題が見つかった場合は修正し、新しい security-auditor サブエージェントで Round 3 を実施します
4. 最大 3 ラウンドまでとし、ユーザーへの直接の質問によって対応をエスカレーションします
5. Round 1 で問題がなければレビューは終了です。 問題が見つかった場合は修正し、新しいサブエージェントを起動して Round 2 を実施します。メインエージェントは自分の作業を正当化しがちですが、新しい視点なら見落とされた問題を発見できます。

機密性の高い関数へのすべてのエントリーポイントを追跡するには、python .claude/scripts/code_graph query callers_of <function> --json を実行してください。

グラフインテリジェンス（graph.db がある場合に推奨）

.code-graph/graph.db がある場合は、構造クエリを使って分析を強化してください。

• 機密性の高い関数へのデータフローを追跡する： python .claude/scripts/code_graph query callers_of <function> --json
• この関数が呼び出す関数を確認する： python .claude/scripts/code_graph query callees_of <function> --json
• 一括分析： python .claude/scripts/code_graph batch-query file1 file2 --json

グラフクエリのパターンについては、上記の `` ブロックを参照してください。

データフロー分析のためのグラフ追跡

グラフ DB が利用できる場合は、trace を使用してセキュリティレビューのデータフロー経路を分析してください。

• python .claude/scripts/code_graph trace <entry-point> --direction downstream --json — 入力からすべての利用先までのデータフローを追跡します（信頼できないデータの移動先を特定します）
• python .claude/scripts/code_graph trace <sensitive-file> --direction upstream --json — 機密性の高いコードに到達するすべてのエントリーポイントを特定します
• トレースによって、データが信頼境界を越えるサービス間の MESSAGE_BUS フローが明らかになります

---

ワークフローの推奨

必須・重要・要対応 — 例外なし： すでにワークフロー内にいない場合は、ユーザーへの直接の質問を必ず使って確認してください。タスクの複雑さを判断したり、「簡単だから省略できる」と決めたりしないでください。ワークフローを使うかどうかを決めるのはあなたではなくユーザーです。

1. quality-audit ワークフローを有効にする（推奨） — security → sre-review → test
2. $security を直接実行する — このスキルを単独で実行

フェーズ 1：Why-Review による自己検証ゲート（指摘事項がある場合は必須）

目的： 引き継ぎ前に、自身の指摘事項を敵対的に検証します。重大度の高すぎる指摘、誤検知、重大度の水増しを、後続工程に伝播させるのではなく、発生源で検出します。

トリガー： 指摘事項（Critical、High、Medium、または Low）が 1 件でもある場合。レポートの判定が無条件の PASS で、指摘事項が文字どおり 0 件の場合に限りスキップします。

手順：

1. 自身の最終確定レポート plans/reports/{skill}-{date}-{slug}.md を読みます
2. $why-review スキルを次の引数で呼び出します：validate findings in plans/reports/{skill}-{date}-{slug}.md — verify each finding has file:line proof, steel-man each rejected interpretation, and stress-test severity classifications
3. why-review の出力を plans/reports/why-review-{date}.md から読みます
4. why-review が指摘事項の重大度を引き下げる、または削除した場合： 自身の最終確定レポートを更新して重大度を修正し、誤検知を削除したうえで、変更内容と理由を記載した ## Why-Review Validation Notes セクションを追加します
5. why-review がすべての指摘事項を確認した場合： 「All N findings re-validated against actual code; no severity changes.」と記載した ## Why-Review Validation 行を自身のレポートに追記します

スキップ条件（スキップする場合は明確な理由を記録してください）：

• 判定が無条件の PASS で、指摘事項が 0 件 → 「Skipped — no findings to validate」と記録します
• why-review スキル自体が現在のコンテキストである（再帰を避けるため）

この手順が必要な理由： AI サブエージェントのレポートには確証バイアスが引き継がれます。オーケストレーターは重大度の主張を事実として受け入れてしまいます。2026-05-09 のレビューインシデントでは High が 5 件報告されましたが、敵対的検証によってそのうち 3 件の重大度が引き下げられました。これを標準的なプラクティスとして定めます。

---

次のステップ

このスキルの完了後、必ず例外なく、ユーザーへの直接の質問で以下の選択肢を提示してください。 タスクが「単純」または「明白」に思えても、スキップしてはいけません。決定するのはユーザーです。

• 「$sre-review（推奨）」 — 本番環境への準備状況をレビューします
• 「$performance」 — 次にパフォーマンスを分析します
• 「スキップして手動で続行」 — ユーザーが決定します

[IMPORTANT] 作業を始める前に、タスク追跡を使ってすべての作業を小さなタスクに分割してください。読み込むファイルごとのタスクも含めます。これにより、長いファイルによるコンテキストの喪失を防げます。簡単なタスクの場合も、AI はスキップするかユーザーに確認しなければなりません。

• docs/project-reference/domain-entities-reference.md — ドメインエンティティの一覧、関係、サービス間同期（タスクにビジネスエンティティ／モデルが関係する場合に読みます）（関連する場合は直接読み、フックによって会話に注入されたテキストに頼らないでください）

外部メモリ： 複雑または長時間に及ぶ作業（調査、分析、スキャン、レビュー）では、中間の調査結果と最終結果を plans/reports/ 内のレポートファイルに記録してください。これにより、コンテキストの喪失を防ぎ、成果物として残せます。

証拠ゲート： 必須です。 すべての主張、指摘事項、推奨事項には、file:line による証拠、または信頼度（％）付きの追跡可能な証拠が必要です。実施に進むのは信頼度が 80％を超える場合に限り、80％未満の場合は先に検証してください。

サブエージェントの選定 — ルーティングの詳細な規則：.claude/skills/shared/sub-agent-selection-guide.md ルール： 専門領域（アーキテクチャ、セキュリティ、パフォーマンス、DB、E2E、統合テスト、git）は、対応する専門エージェントに割り当ててください（上記のガイドを参照）。これらに code-reviewer を使ってはいけません。理由：code-reviewer には各領域のチェックリストがないため、専門的な問題を見落とします。 グラフを活用した調査 — .code-graph/graph.db が存在する場合は必須です。

厳格な必須条件： 調査を完了する前に、主要なファイルを対象とするグラフコマンドを少なくとも 1 つ実行する必要があります。

パターン： Grep でファイルを特定 → trace --direction both でシステム全体のフローを把握 → Grep で詳細を検証

タスク	グラフ操作の最低要件
調査／偵察	2～3 個のエントリーファイルに対して trace --direction both を実行
修正／デバッグ	バグのある関数に対する callers_of と tests_for
機能追加／拡張	変更対象ファイルに対する connections
コードレビュー	変更した関数に対する tests_for
影響範囲	trace --direction downstream

CLI： python .claude/scripts/code_graph {command} --json を使用します。まず --node-mode file を使用してノイズを 10～30 分の 1 に抑え、その後、詳細を確認するために --node-mode function を使用します。

結果の逐次保存 — 3 ファイルを超えて処理するすべてのサブエージェントまたは負荷の高いインライン処理で必須です。

1. 開始前： レポートファイル plans/reports/{skill}-{date}-{slug}.md を作成します
2. 各ファイル／セクションの確認後： メモリに保持せず、直ちに調査結果をレポートに追記します
3. メインエージェントへの返却：（SYNC:subagent-return-contract に従い）要約のみを返し、Full report: にパスを記載します
4. メインエージェント： 個別のブロッカーを解決する場合にのみレポートファイルを読みます

理由： 実行途中でコンテキストが切れると、メモリ内の調査結果はすべて失われます。ディスクへの書き込みは圧縮後も残ります。部分的な結果でも、結果がまったくないより有用です。

レポートの命名規則： plans/reports/{skill-name}-{YYMMDD}-{HHmm}-{slug}.md

サブエージェント返却契約 — このスキルがサブエージェントを起動した場合、サブエージェントは次の構成のみを返す必要があります。メインエージェントが読むのはこの要約のみです。インラインでサブエージェントの出力全体を要求することはありません。

## サブエージェントの結果：[skill-name]

Status: ✅ PASS | ⚠️ PARTIAL | ❌ FAIL
Confidence: [0-100]%

### 調査結果（重大／高のみ — 箇条書き最大 10 件）

- [severity] [file:line] [finding]

### 実施した対応

- [file changed] [what changed]

### ブロッカー（該当する場合）

- [blocker description]

Full report: plans/reports/[skill-name]-[date]-[slug].md

メインエージェントが Full report ファイルを読むのは、次の場合に限ります。（a）特定のブロッカーを解決する場合、または（b）修正計画を作成する場合。 サブエージェントは、レポート全体をメモリに保持せず、逐次的に書き込みます（SYNC:incremental-persistence に従います）。

批判的思考の姿勢 — 批判的思考と段階的思考を適用します。すべての主張に追跡可能な根拠が必要であり、行動するには確信度が 80% を超えている必要があります。 ハルシネーション防止： 推測を事実として提示してはいけません。すべての主張に出典を示し、不確実性を率直に認め、出力に誤りがないか自己確認し、独立した情報源と照合して、自分の確信度にも懐疑的でいてください。根拠のない確信は、あらゆるハルシネーションの根源です。

根拠に基づく推論 — 推測は禁止です。すべての主張に根拠が必要です。

1. すべての主張について、file:line、Grep の検索結果、またはフレームワークのドキュメントを引用します
2. 確信度を明示します：80% 超ならそのまま行動、60～80% なら先に検証、60% 未満なら推奨しないでください
3. アーキテクチャの変更には、サービス間の検証が必要です
4. 「根拠が不十分です」は有効であり、期待される出力です

次の項目が満たされるまで作業はブロックされます： - [ ] 根拠となるファイルパス（file:line） - [ ] Grep 検索を実施済み - [ ] 類似パターンを 3 件以上確認済み - [ ] 確信度を明示済み

根拠なしでの使用禁止： 「明らかに」「〜と思います」「〜のはずです」「おそらく」「これは〜が原因です」 未完了の場合 → 次を出力します："Insufficient evidence. Verified: [...]. Not verified: [...]." ソース／テストの乖離チェック。 コーディング、修正、デバッグ、調査、テスト、レビューの作業では、ソースの動作が変わったとき、影響を受けるユニット／統合／E2E テストを調べ、意図した動作に合わせてテストを変更すべきか、それともソースの変更が意図しないバグであり修正すべきかを、証拠に基づいて判断してください。マイグレーションコードのテストは作成しないでください。スキーマ／データのマイグレーションは一度だけ実行される処理であり、アプリケーションの中核ロジックではありません。

AI のミス防止 — すべてのタスクで避けるべき失敗パターン：

削除する前に、下流の参照を確認してください。 コンポーネントを削除すると、ドキュメントやコードに古さが波及します。削除する前に、参照しているファイルをすべて特定してください。 AI が生成した内容を実際のコードと照合してください。 AI は API、クラス名、メソッドシグネチャを幻覚します。ドキュメント化したり参照したりする前に、必ず grep で存在を確認してください。 編集後は依存関係の全体をたどってください。 定義を変更しても、そこから派生する下流の変数や利用箇所を見落とすことがあります。必ず依存関係の全体をたどってください。 正しさを検証するときは、すべてのコードパスをたどってください。 コードが存在することを確認しても、実行されることの確認にはなりません。正常系だけでなく、早期リターン、エラーブランチ、条件によるスキップも必ずたどってください。 デバッグ時は、修正する前に「誰の責任か？」を確認してください。 バグが呼び出し側（誤ったデータ）にあるのか、呼び出される側（誤った処理）にあるのかをたどってください。責任のあるレイヤーで修正し、症状が現れる箇所だけを修正することは避けてください。 既存の値は意図的に設定されていると考え、変更前に理由を確認してください。 定数、制限値、フラグ、パターンを変更する前に、コメントを読み、git blame を確認し、周辺のコードを調べてください。 最初の出力だけでなく、影響を受けるすべての出力を検証してください。 複数のスタックにまたがる変更では、すべての出力を検証する必要があります。チェックが 1 つ通っても、すべてのチェックが通ったことにはなりません。 全体を優先するデバッグ — 目の前に注意を奪われる罠を避けてください。 失敗を調査するときは、まず前提条件をすべて列挙してください（設定、環境変数、DB 名、エンドポイント、DI 登録、データの前提条件）。次に、コードレイヤーの仮説を立てる前に、それぞれを証拠と照らし合わせて検証してください。 最小限の変更 — 差分テストを適用してください。 バグ修正では、変更した各行がバグに直接つながっている必要があります。隣接するコードのスタイル変更や改善はしないでください。機能強化のタスクでは、改善を実装し、その内容を明示的に伝えてください。 コーディングの前に曖昧さを明らかにしてください — 黙って解釈を決めないでください。 依頼に複数の解釈がある場合は、それぞれに必要な作業量の見積もりを添えて提示し、確認してください。全レコード対象、ファイルベース、またはより複雑な方法だと決めつけないでください。

重要・必ず注意 すべての主張について file:line の証拠を示してください。確信度が 80% を超える場合にのみ実行し、60% 未満の場合は推奨しないでください。

重要・必ず注意 graph.db が存在する場合は、主要なファイルに対してグラフコマンドを少なくとも 1 つ実行してください。手順：grep → trace → verify。

必ず注意 批判的思考を適用してください — すべての主張には、追跡可能な証拠が必要です。実行するのは確信度が 80% を超える場合に限ってください。幻覚を防ぐため、推測を事実として提示してはいけません。

必ず注意 AI のミス防止を適用してください — 全体を優先するデバッグ、責任のあるレイヤーでの修正、コーディング前の曖昧さの明示、コンパクション後のファイルの再読を徹底してください。

プロンプト強化の締めくくりアンカー

重要・必ず注意 このスキルで定められた手順の順序に従ってください。ユーザーから明示的な承認を得ずに、手順を省略、並べ替え、または統合してはいけません。 重要・必ず注意 手順／サブスキルを呼び出すたびに、実行前に in_progress に設定し、実行後に completed に設定してください。 重要・必ず注意 省略した手順には必ず明示的な理由を記載してください。完了した手順には必ず簡潔な証拠を記載してください。 重要・必ず注意 Task ツールを利用できない場合は、同等の手順ごとの計画トラッカーを維持し、ステータスを同期してください。

終了時の注意事項

必須・重要・必ず注意 作業を開始する前に、タスク追跡を使って作業を小さな TODO タスクに分割してください。 必須・重要・必ず注意 判断は、ユーザーに直接質問して確認してください。自動的に決めてはいけません。 必須・重要・必ず注意 作業の品質を確認するための最終レビュー TODO タスクを追加してください。 必須・重要・必ず注意 作業を開始する前に、以下のファイルを読んでください。

[タスク計画] 作業に着手する前に、タスクの範囲を分析し、タスク追跡を使って小さなタスクとサブタスクに体系的に分割してください。

[重要] タスクの規模を分析し、作業を始める前に体系的に多くの小さなタスクへ分割してください。これは非常に重要です。

フックなしプロンプトプロトコルのミラー（自動同期）

参照元：.claude/hooks/lib/prompt-injections.cjs + .claude/.ck.json

[WORKFLOW-EXECUTION-PROTOCOL] [BLOCKING] ワークフロー実行プロトコル — 必須・重要・必ず守ること。いかなる理由があっても省略しないでください。

汎用的な移植性の境界： 再利用可能なスキルとプロトコルのテキストはプロジェクトに依存しないものとします。プロジェクト固有の規約は docs/project-config.json と docs/project-reference/ から確認してください。共有 AI-SDD は shared/sdd-artifact-contract.md を適用してください。docs/project-config.json と docs/project-reference/docs-index-reference.md を読み、そこに記載されたプロジェクト参照ドキュメントを開いてください。共有コンテキストとローカルドキュメントが利用可能であれば、サポート対象の AI ツールで実行できます。

1. 検出： プロンプトをワークフローカタログと照合します
2. 分析： 最適なワークフローを見つけ、カスタムのステップの組み合わせがより適しているかも評価します
3. 確認（必須の形式）： ユーザーが明示的にワークフロー／スキルを呼び出し、ローカルプロトコルでその明示的な呼び出しを確認とみなす場合を除き、次の形式でユーザーに直接質問します。
   • 質問：「どのワークフローを有効にしますか？」
   • 選択肢 1：「[最適なワークフロー] を有効にする（推奨）」
   • 選択肢 2：「カスタムワークフローを有効にする：[ステップ1 → ステップ2 → ...]」（理由を1行で記載）
4. 有効化（確認後）： 標準ワークフローでは $workflow-start <workflowId> を呼び出します。カスタムのステップは手動で順に実行します
5. タスクの作成： すべてのワークフローステップについて、タスク追跡でタスクを作成します
6. 実行： 各ステップを順番に実行します [CRITICAL-THINKING-MINDSET] 批判的思考と順序立てた思考を適用してください。すべての主張には追跡可能な根拠が必要であり、確信度が80％を超える場合にのみ実行してください。 反ハルシネーションの原則： 推測を事実として提示してはいけません。すべての主張について情報源を引用し、不確実性は率直に認め、出力の誤りをセルフチェックし、独立した情報源と相互参照し、自身の確信度を懐疑的に検証してください。根拠のない確信は、あらゆるハルシネーションの根源です。 AI 注意力の原則（初頭効果・新近効果）： 長いプロンプト／プロトコルでは、指示への準拠が長いコンテキストウィンドウでも維持されるよう、最重要ルール3つを冒頭と末尾の両方に配置してください。 目標主導の実行： まず成功基準を定義し、検証が完了するまで繰り返し、観察可能なチェックに合格した時点でのみ終了してください。 テストで意図を検証： テストは、現在の動作を単に反映するだけでなく、ビジネスルール／不変条件を保護し、保護対象の意図が損なわれた場合に失敗する必要があります。

[LESSON-LEARNED-REMINDER] [BLOCKING] タスク計画と継続的改善 — 必須。省略しないでください。

作業を始める前に、作業を小さなタスクに分けて（タスク追跡を行って）ください。最後のタスクとして「AI のミスと教訓を分析する」を追加してください。

教訓を抽出する — 症状への対処ではなく、根本原因のみ：

1. 症状ではなく、失敗モード（推論や前提の誤り）に名前を付けます。「誤った列挙値を使った」ではなく、「ソースを読まずに API が存在すると仮定した」。
2. 汎用性を確認します。この失敗モードは、3 つ以上の状況やコードベースに当てはまりますか？当てはまらない場合は、もう 1 段階抽象化してください。
3. 普遍的なルールとして記述します。プロジェクト固有の名前、パス、クラスを取り除き、どのコードベースでも役立つ内容にしてください。
4. まとめます。同じ失敗モードに起因する複数のミスは、1 つの教訓にまとめてください。
5. 再発確認：「このリマインダーがなくても、今後のセッションで再発しますか？」いいえの場合は、$learn を省略します。
6. 自動修正確認：「$code-review／$code-simplifier／$security／$lint で検出できますか？」はいの場合は、代わりにレビューのスキルを改善してください。
7. **両方の確認を通過した場合：**ユーザーに $learn の実行を依頼してください。 [TASK-PLANNING] [MANDATORY] ワークフローやスキルの手順を実行する前に、計画したすべての手順についてタスク追跡を作成または更新してください。その後、各手順の開始時と完了時に、タスク追跡の内容を同期してください。