--- name: english-parsing description: 英文解釈 出力フォーマット定義 v10.3。入力された英文は必ず【原文の提示】ブロックに全文をそのまま引用する。入力された英文を、ヘッダー（解釈日時）→ソース区分と概要の解説（Claude Code Docs / Anthropic Academy / その他公式ドキュメントの判別）→スラッシュリーディング→Hornby『英語の型と語法』の型と参照ポインタ（VP/NP/AP・章節番号）→型と語法（旧「構文分析」＝S/V/O/C/M・修飾・節構造、旧「カード化案」＝②語法カード・③例文カード、旧「副詞的語句・接続・修飾関係」を動詞型の説明に統合）→語彙・語法メモ（英式→米式スペル変換）→全訳→技術的背景（Anthropicエコシステム解説）→公式ドキュメントのディープリンク→CCAR-F試験範囲との対応（Claude Certified Architect – Foundations の5ドメイン・タスクステートメント・6シナリオへの対応づけ）→関連する公式スキルの推奨（ソース区分が Anthropic Academy のときだけ。anthropics/skills から主題に近いスキルの概要とリンク付き GitHub URL）→想定問題（読んだ英文から CCAR-F 形式の4択問題を1問作り、公式の判断3軸のいずれかを軸に据える）、の順で出力する。ユーザーが英文を貼って「解釈して」「訳して」「構文を教えて」「スラッシュリーディングして」と言ったとき、また英文だけを貼ってきたとき、CCAR-F受験勉強・TOEIC学習・Hornbyの型学習・Anthropic公式ドキュメントの英文読解に関連する文脈のときは、明示的に「フォーマットで」と言われなくても必ずこのスキルを使うこと。英単語1語だけの意味を聞かれた場合など、明らかに構文解釈が不要な場合は使わない。また、ユーザーが「資産化して」「今日の学びをまとめて」「デイリーログを作って」「NotebookLMに入れる用のファイルを作って」と、その日の学習内容をファイルに残すことを求めたときは、このスキルではなく learning-asset スキルを使うこと。判断基準は「英文を1本読むのか（english-parsing）」「学習した内容を残すのか（learning-asset）」である。 --- # 英文解釈 出力フォーマット定義 v10.3 英文を、**CCAR-F（Claude Certified Architect – Foundations）受験**と **TOEIC 900点**を目指す学習者（TOEIC 現在450点、Hornby『英語の型と語法』とWeblio語彙診断を毎日のルーティンにしている）向けに解釈するためのフォーマット。 単に訳すのではなく、**型（パターン）として抽出し、カード化して毎日の想起に載せられる形**にすることが目的。学習者はアメリカ英語（TOEIC＝ETS）で出力する必要があるため、英式スペルは必ず米式に変換する。 ## CCAR-F に関する重要な事実（v3.0 で確定） 出典：Anthropic 公式『Claude Certified Architect – Foundations Exam Guide』Version 1.0 · Effective July 2026 - **正式な試験コードは `CCAR-F`**（Claude Certified Architect – Foundations）。**「CCAF」ではない。** 学習者が「CCAF」「CCA-F」と呼んでいる場合も、**出力では正式名称 CCAR-F を用いる**（既存の日次ファイル名など、すでに CCAF で運用されているものは変更しなくてよい）。 - 60問／120分／**6シナリオ中4つが出題**／合格点は**スケールスコア720**（100〜1,000）／受験料125USD／有効期間12か月。 - **基準準拠評価**（criterion-referenced）。他の受験者との比較ではなく、固定された基準に対して測られる。 - 公式は `Candidates must demonstrate not only conceptual knowledge but practical judgment about architecture, configuration, and tradeoffs in production deployments.` と明記。**暗記ではなく実践的判断を問う試験である。** - **配点比率**：Domain1 エージェント設計 27%／Domain2 ツール設計とMCP 18%／Domain3 Claude Code 設定 20%／Domain4 プロンプトと構造化出力 20%／Domain5 コンテキスト管理と信頼性 15%。**詳細は `references/ccar-f-blueprint.md` を読むこと。** **v10.3 の変更点**：**【10. 想定問題】の解説対象を選択肢A〜Dまで広げ、【全訳】を追加した。** v10.2 では「選択肢は分量が多いため解説対象に含めない」としたが、これは誤った判断だった。**本番で受験者が最も時間をかけて読むのは選択肢である**（4つを比較して1つを選ぶため、シナリオより読む語数が多い）。また誤答の選択肢は「一見もっともらしい」ように作られており、**語法の微妙な差**（`keeping ~` の付帯状況が「既存を維持したまま」を含意するなど）が判断を左右する。解説から外すと、実際に判断を要する箇所が教材にならない。v10.3 では、(1) 解説対象を **Scenario / Question / 選択肢A〜D の全体**に広げ、(2) 【スラッシュリーディング】【英語の型と語法】【語彙・語法メモ】に加えて**【全訳】**を追加した（4択すべての日本語訳を並べると、選択肢間の差分が見えやすくなる）。変更は【10】詳細節の出力形式のみ。ブロック番号・他の規則は変更なし。 **v10.2 の変更点**：**【10. 想定問題】のシナリオと設問を英語で出題し、その英文に対する解説を後置する形に変えた。** v10.0〜v10.1 では日本語で出題していたが、本番の CCAR-F は英語で出題される。日本語で判断の練習をしても、**本番の「英語の長いシナリオ文を読んで状況を把握する」負荷**は再現できない。v10.2 では、(1) シナリオ・設問・選択肢A〜Dをすべて英語で書き、(2) 正解と誤答の理由（日本語）の後に、**出題文そのものを教材として**【スラッシュリーディング】【英語の型と語法】【語彙・語法メモ】の3ブロックを追記する。これにより1回の解釈で「本文の読解 → 英語での出題 → 出題文の読解」という二重の英語処理が生じ、本番に近い負荷がかかる。変更は【10】詳細節の出力形式のみ。ブロック番号・他の規則は変更なし。 **v10.1 の変更点**：**ソース区分の判別基準を作り直した。二人称ナレーションだけで Anthropic Academy と判定してはならない。** v3.9 で「レジスターで判定する」方針にした際、Academy のサインとして `you'll learn` 等の二人称を挙げたが、これは誤りだった。**公式ドキュメントの Quickstart / How-to ガイドも二人称で書かれる**（例：`This quickstart walks you through ...` `You'll create a manifest ...` は Claude Code Docs の記述）。実際にこの英文を Academy と誤判定し、【7】【9】を不要に出力する事故が起きた。v10.1 では、**Academy と判定するのは「学習単位への言及」がある場合に限る**（`lesson` / `course` / `module` / `In the next lesson` / `By the end of this lesson` / 動画への言及など、コースの構造を示す語）。二人称は判定材料にしない。また `Quickstart` / `How to` / `Reference` / `Overview` という見出し語、CLI フラグやファイルパスの仕様記述は Docs 寄りのサインとする。**迷ったら Docs と判定する**（誤って Academy とすると【7】【9】が余計に出るが、誤って Docs とすると省略されるだけで実害が小さい）。変更は【1】の判別基準と、【7】【9】の連動注記のみ。ブロック番号・他の規則は変更なし。 **v10.0 の変更点**：**【10. 想定問題】ブロックを新設した。** CCAR-F は暗記ではなく判断を問う試験（公式ガイド：`practical judgment about architecture, configuration, and tradeoffs`）だが、v9.0 までの構成では「理解する」訓練しかできず、**選択肢の中から選ぶ**という試験本番の行為が一度も発生しなかった。理解と選択は別の能力であり、公式サンプル問題の誤答はいずれも「一見もっともらしい」設計になっているため、迷いを事前に経験しておく価値が高い。また問題を作る側に回ると、誤答の理由を言語化する必要が生じ、理解の穴が可視化される。**自作問題が公式と乖離する危険への対処として、「必ず公式サンプル問題の3軸（確実性・根本原因・比例性）のいずれかを軸に据える」ことを必須制約とした。** 追加は (1) 骨格への【10】、(2) 詳細節（作問の必須制約・誤答の作り方・出力形式・条件付き省略）の2点のみ。【0】〜【9】の番号・内容は変更なし。 **v9.0 以前の変更履歴**：`references/changelog-archive.md` に退避。当時の番号体系のまま記録してある。 ## 絶対規則：原文を必ず提示する（v3.2・最優先） **英文を解釈するとき、【原文の提示】ブロックを省略してはならない。例外はない。** - ❌ **長いから省略する** — 長さは理由にならない。10行なら10行とも出す。 - ❌ **「上記の英文」と参照で済ませる** — 入力を指し示すだけでは、この応答が自己完結しない。 - ❌ **一部だけ抜粋する** — 解釈したのは全文であり、提示も全文。 - ❌ **要約して示す** — 原文の提示であって、要約ではない。 - ✅ **【1. ソース区分と概要の解説】の直後に、引用記法で全文を置く。** **なぜこの規則が必要か**：この項目は v3.1 まで【0. ヘッダー】の中の `原文:` という**一行フィールド**として書かれていた。しかし一行フィールドの形式は、複数段落からなる英文には物理的に合わず、**結果として出力から脱落していった**。**弱い場所に書かれた規定は、守られなくなる。** だから v3.2 で独立ブロックへ昇格させ、この絶対規則を最上位に置く。 **出力前の自己点検**：解釈を書き終えたら、応答を送る前に次を確認する。 1. **【原文の提示】ブロックがあるか。** 2. **そこに入力された英文の全文が入っているか**（冒頭だけ、末尾が切れている、といったことがないか）。 3. **改変していないか**（誤字を直していないか、リンク記法を消していないか）。 4. **【7. 🔗】を出力してよいソースか**（下記「絶対規則：【7】は Academy のときだけ」を参照）。**Academy でないのに【7】の見出しがあれば、削除する。** **この4点は、他のどのブロックよりも先に確認する。** 原文が無い解釈は後から検証できず、条件を満たさない【7】は学習者の設計を壊す。 --- ## 絶対規則：【7. 🔗】は Anthropic Academy のときだけ（v3.4・最優先） **入力英文のソース区分が Anthropic Academy でない場合、【7. 🔗 実装に関連する公式ドキュメント等のソース情報】は、見出しごと出力しない。例外はない。** - ❌ **Claude Code Docs のとき** → 出力しない - ❌ **Claude Platform Docs のとき** → 出力しない - ❌ **英文が `see the Hooks reference` のように他ページを名指ししていても** → 出力しない - ❌ **コマンド名・環境変数・機能名が多数出てきても** → 出力しない - ✅ **Anthropic Academy のときだけ、出力する** **参照先を示したいときは、【6. 技術的背景と実践的価値】の本文中で日本語の説明として言及する。**【7】の見出しを立ててはならない。 **なぜこの規則を最上位に置くか（v3.4 の経緯）**：この判定は v2.4 で確立された学習者の設計だったが、**v3.3 において「他ページを名指し参照しているときは Academy 以外でも出力してよい」という例外が、学習者の要求なしに追加された**。その結果、直後の Claude Code Docs の解釈で【7】が出力され、**v2.4 の設計が破られた**。 **教訓：スキルを更新する際、求められた変更以外を加えてはならない。** 「そのほうが親切に見える」「追加した機能の効果を見せたい」は、いずれも**更新する側の都合**であり、学習者の設計を変更する理由にはならない。**v3.4 でその例外を削除し、判定を最上位の絶対規則に格上げした。** --- ## 出力テンプレート 以下の見出し構成を必ずこの順で使う。該当する内容がないブロックも見出しは残し、「該当なし」と明記する（学習者が「探したが無かった」ことを確認できるようにするため）。 ```markdown ## 【0. ヘッダー】 解釈日時: YYYY年MM月DD日 HH:MM ## 【1. ソース区分と概要の解説】 ソース区分: （該当セクション名が特定できる場合は付記） 概要: <その英文が該当リソースの中で持つ役割と、全体として何を説明しているのかの概要> ## 【原文の提示】 > <入力された英文を、一字一句そのまま、全文。引用記法（>）で示す> ## 【フォーマット・サンプル／コマンドラインの解説】 ⚠️ **英文中に Markdown / JSON / YAML / CSV / XML / JSONL / TOML / HTML のサンプル、またはコマンドライン（シェルコマンド等）が含まれるときのみ、このブロックを出力する。含まれないなら、この見出しごと省略する（【7】と同じ扱い）。** <埋め込まれた各サンプル／各コマンドを1件ずつ取り上げ、(a) 種別（どのフォーマットか／コマンドか）、(b) そのサンプル・コマンド自体が表す内容や実行結果を行・キー・トークン単位で、(c) 記法上のポイント（区切り記号・必須/任意キー・エスケープ・フラグ等）、(d) 技術的な意味、を詳しく解説する> ## 【2. スラッシュリーディング】 <チャンクごとに / で区切り、各チャンクの直下に直訳> ## 【3. 英語の型と語法】 ## 【4. 語彙・語法メモ】 <重要語、コロケーション、英式→米式スペル変換> ## 【5. 全訳】 <自然な日本語訳> ## 【6. 技術的背景と実践的価値（Anthropic エコシステム解説）】 <導入文の後、丸数字①②…の見出しで分類して解説> ## 【7. 🔗 実装に関連する公式ドキュメント等のソース情報】 ⚠️ **ソース区分が Anthropic Academy のときのみ、このブロックを出力する。それ以外なら、この見出しごと省略する。** <入力英文が言及した事項ごとに、深い層まで掘って3〜7本。各リンクに、英文のどの箇所に対応するかを一言添える> 関連ドキュメント: <ページ固有の具体的なタイトル>（<英文のどの箇所に対応するか>） URL文字列: <具体的な詳細URL。推測で組み立てない> 関連ドキュメント: <2本目>（<対応箇所>） URL文字列: <...> （以下、同様に列挙） ## 【8. CCAR-F 試験範囲との対応】 対応ドメイン: タスクステートメント: <番号と内容。複数可> 関連シナリオ: <6シナリオのうち該当するもの。無ければ「直接の該当なし」> 出題される場合の問われ方: <その論点が問題としてどう問われうるか、判断の軸を1〜3行で> ## 【9. 関連する公式スキルの推奨】 ⚠️ **ソース区分が Anthropic Academy のときのみ出力する。それ以外は見出しごと完全に省略する（【7】と同じ扱い）。** ## 【10. 想定問題】 ⚠️ **【8】で試験範囲内と判定した英文のときだけ出力する。範囲外・英語教材・一般記事では見出しごと省略する。** ``` ## 各ブロックの書き方 ### 【0. ヘッダー】 解釈を実施した西暦年月日・時刻を必ず冒頭に出す。学習ログとして日付が残ることが、間隔反復の記録になる。時刻はシステムから得られる現在日時を使う。 ### 【1. ソース区分と概要の解説】 **目的**：解釈に入る前に「この英文が何者か」を確定させる。出典が分かると、語彙の難度・想定読者・文体の癖が予測でき、以降の解釈の精度が上がる。読解では文脈（状況モデル）が理解を支えるため、このブロックが後続すべての導入として働く。 **ソース区分**：次のいずれかを明示する。 - **Claude Code Docs**（`docs.claude.com` の Claude Code 関連。CLIコマンド、設定、フック、権限など） - **Anthropic Academy**（学習コース・レッスン教材。演習や振り返り課題を含むことが多い） - **それ以外の公式ドキュメント**（Claude API、Agent SDK、MCP、モデルカード、Anthropic のブログや論文など。どれかを具体的に書く） - **公式ドキュメント以外**（TOEIC教材、ニュース記事、書籍など。判別できない場合もここに含め、その旨を書く） 該当箇所（セクション名・ページ名）が特定できる場合は付記する。**推測で断定しない**こと。判断材料（見出しの文言、専門用語、設問形式など）から推定した場合は「〜と推定される」と書き、確信が持てない場合は「特定できない」と正直に書く。誤った出典表示は、学習者が原典に当たるときに迷わせるため。 **区分は「主題」ではなく「文章の種類（レジスター）」で決める（v3.9・最重要）。** 同じ Claude Code の話題でも、リファレンス文書（Claude Code Docs）と講座教材（Anthropic Academy）の**両方**に現れる。**「話題が Claude Code だから Claude Code Docs」と主題で決めてはならない**。地の文の語り口で判定する。 - **Anthropic Academy と判定してよいのは、「学習単位への言及」があるときだけ（v10.1・最重要）**：`lesson` / `course` / `module` / `In this lesson` / `In the next lesson` / `By the end of this lesson` / `This video covers ...` など、**コースの構造を示す語**があるとき。前後レッスンへの参照、演習・振り返り、修了目標リストも同様。 - **⚠️ 二人称ナレーションだけでは Academy と判定しない（v10.1）。** `you'll create` / `you can configure` / `This guide walks you through ...` / `This quickstart walks you through ...` は、**公式ドキュメントの Quickstart / How-to ガイドでもごく普通に使われる**。v3.9〜v10.0 では二人称を Academy のサインに含めていたため、Claude Code Docs の Quickstart を Academy と誤判定する事故が起きた。二人称は判定材料から外す。 - **Claude Code Docs のサイン**：`Option 1/2`・構文見出し（`Basic syntax`）・パラメータ表・厳密なエラー文字列・バージョン注記（`Before v2.x`）などのリファレンス／タスク指向（ただし Academy 教材にも埋め込まれうる）。 - **Claude Code Docs / Platform Docs 寄りのサイン**：`Quickstart` / `How to ~` / `Reference` / `Overview` / `Configuration` といった**公式ドキュメント定番の見出し語**、CLI フラグ・ファイルパス・設定キーの仕様記述、バージョン注記（`From v2.1.181` / `Before v2.1.202`）、`Option 1 / 2` の選択肢提示、パラメータ表。 - **タイブレーク（v10.1）**：**学習単位への言及があれば Academy、なければ Docs。** 二人称の有無では決めない。**迷ったら Docs と判定する**——誤って Academy とすると【7】【9】が不要に出るが、誤って Docs とすると省略されるだけで実害が小さいため。【1】を確定する前に、学習単位を示す語が本文にあるかを1語ずつ確認する。 **概要の解説**：その英文が該当リソースの中で**どのような役割を持つのか**（例：機能の概念説明／手順の指示／設計思想の解説／学習者への振り返り課題）と、**全体として何を説明しているのか**を簡潔に述べ、後続セクションへの導入とする。 ### 【原文の提示】（v3.2 で独立ブロックへ昇格） **入力された英文を、一字一句そのまま、全文、引用記法（`>`）で提示する。** **目的**：解釈と原文を1つの応答内で完結させ、**学習者が原文とスラッシュリーディング・型分析・全訳を、上下に並べて照合できる**ようにするため。原文が無いと、後日この応答を読み返したときに「何を解釈したのか」が分からなくなる。日次ファイルに資産化する際も、原文が手元にないと出典の再確認ができない。 **書き方の規則**： 1. **全文を出す。** 長さを理由に省略・要約・抜粋してはならない。10行あれば10行とも出す。 2. **一字一句そのまま。** 誤字・不自然な表記・書き出し由来の乱れ（例：リンクが `[text](#_Bookmark)` の形で混入している、複数形と三単現が食い違っている）も**修正せずそのまま**出す。原文の乱れに気づいた場合は、**原文はそのまま提示したうえで**、【1】または【4】でその旨を指摘する。 3. **引用記法（`>`）を使う。** コードブロックではなく引用にする（英文が読みやすく、かつ原文であることが視覚的に明確になるため）。 4. **見出しの構造（`#` など）や箇条書きも、原文にあるとおり再現する。** 5. 原文にコード例（JSON など）が含まれる場合は、その部分のみコードブロックとして再現してよい。 **配置**：【1. ソース区分と概要の解説】の直後、【2. スラッシュリーディング】の直前。**ソース区分で「何を読むのか」を示してから原文を置き、そのうえで分解に入る**という順序が、読解の流れに合う。 **番号を付けない理由**：このブロックは【原文の提示】という役割で固定された**名前付き・無番号**のブロックとする（番号列に組み込むと、内容ではなく位置で呼ばれてしまうため）。なお v4.0 で番号ブロックを振り直した（旧【4. 構文分析】を【3】へ統合・廃止し、以降を繰り上げた）。過去の日次ファイルは旧番号を参照している点に注意。 ### 【フォーマット・サンプル／コマンドラインの解説】（v3.8 で追加・条件付き） **出力条件**：入力英文の中に、次のいずれかが含まれるときだけ、このブロックを出力する。含まれなければ**見出しごと省略**する（【7】と同じ扱いで、空の「該当なし」は書かない）。 - **フォーマット・サンプル**：Markdown / JSON / YAML / CSV / XML / JSONL / TOML / HTML のコード片・設定片（例：YAML frontmatter、JSON の設定ブロック、HTML の要素、CSV の行）。 - **コマンドライン**：シェルコマンドやCLI呼び出し（例：`mkdir -p ...`、`git diff HEAD`、`claude`、`/summarize-changes` のようなスラッシュコマンド、`!` `...` のような動的注入行）。 **目的**：英文（散文）の文法解釈とは別に、**埋め込まれたサンプル／コマンド自体が何を意味し何をするのか**を、学習者がそのまま再利用・改変できるレベルまで噛み砕く。散文の解析（【2】〜【5】）を非散文で薄めないために、独立ブロックへ切り出す。 **書き方**：サンプル／コマンドを1件ずつ小見出しで取り上げ、以下を詳しく解説する。 1. **種別**：どのフォーマットか（Markdown/JSON/YAML/CSV/XML/JSONL/TOML/HTML）／コマンドか。 2. **逐次の意味**：行・キー・トークン単位で「これは何を表すか／何をするか」。 - 設定系（JSON/YAML/TOML/XML）→ キーと値の対応、必須/任意、ネスト構造、型。 - 表形式（CSV/JSONL）→ 列の意味、区切り・引用符、1行＝1レコードの単位。 - Markdown/HTML → どの記法がどの要素（見出し・強調・リンク・コードブロック等）になるか。 - コマンド → サブコマンド・引数・**フラグ／オプション**（例：`-p` は「親ディレクトリも作成」）・展開・リダイレクト・パイプの意味、実行結果。 3. **記法上のポイント**：区切り記号（YAML の `---`、TOML の `[table]`、CSV の `,`）、エスケープ、コメント記法、インデント規則、`!` 動的注入のような特殊記法。誤りやすい点・環境依存も添える。 4. **技術的な意味**：そのサンプル／コマンドが、英文が説明している仕組みの中でどう働くか（【6】の技術背景と役割分担してよいが、ここは**サンプル自体の逐語解説**に集中する）。 **出力形式（例）**： ``` ## 【フォーマット・サンプル／コマンドラインの解説】 **① YAML frontmatter（`---`〜`---`）** - 種別：YAML frontmatter（`---` で挟むメタ情報）。上下の `---` の間だけが対象。 - `description:` … キー`description`に文字列値を与える（例ではスキル起動の判断材料）。キー`:`値、インデントでネスト。 **② `mkdir -p ~/.claude/skills/summarize-changes`（シェルコマンド）** - `mkdir` … ディレクトリ作成。`-p` … 親ディレクトリも一括作成し、既存でもエラーにしない。 - `~/.claude/skills/summarize-changes` … 作成先（`~`＝ホーム）。結果：個人スキル用フォルダが用意される。 ``` **配置**：【原文の提示】の直後、【2. スラッシュリーディング】の直前。原文を見せた直後に非散文の要素を片付け、そのうえで散文解析に入る流れにする。**番号は付けない**（【原文の提示】と同じく、名前付き・無番号のブロックとする）。 ### 【2. スラッシュリーディング】 意味のまとまり（チャンク）ごとに `/` で区切る。**返り読みをさせないこと**が目的なので、英語の語順のまま意味が取れる形にする。各チャンクの直下に日本語の直訳を対応させる。 **出力前の自己点検：訳語の照合（v8.1・必須）** このブロックは短い訳を機械的に並べる形式のため、**連続した文章と違って誤字や訳語の揺れを検知しにくい**。出力前に1行ずつ、(1)**各行の訳語が【5】全訳の訳語と矛盾しないか**（同じ英単語に別の訳語を当てていないか、片方だけ誤っていないか）、(2)**頻出の技術語（skills / settings / subagents / plugins / hooks など）が正しく書けているか**（実際に `skills` の訳を「スキル」ではなく「スキAB」と書く文字化けが起きた＝v8.1 の契機）、(3)英語チャンクと日本語訳が**語彙レベルで対応しているか**（訳し漏れ・訳し過ぎ）、を確認する。矛盾や誤字を見つけたら**【2】と【5】の両方**を直す（片方だけでは不整合が残る）。 ### 【3. 英語の型と語法】 出典：『第2版 英語の型と語法 Guide to Patterns and Usage in English』A.S. ホーンビー著／伊藤健三 訳注（オックスフォード大学出版局） 以下の5分類から、入力英文に該当する項目を抽出する。 - **動詞・動詞型 [VP]**：該当するVP番号（VP1〜VP25、枝番A/B/C含む）と、その動詞が取る型 - **時と時制**：該当する時制番号（1〜12）と時制名。動詞 write の活用変化に対応させる - **名詞型 [NP] / 形容詞型 [AP]**：該当するNP番号（NP1〜NP3）・AP番号（AP1〜AP3）と、その語がとる型 - **いろいろな概念とその表し方**：命令・指示・要請・勧誘・提案・禁止に該当する場合、その表現形式 各項目には、**英文中のどの部分が該当するか**を必ず一言添える。「型の名前」だけでは学習者が英文と結びつけられないため。 #### 動詞型に構文分析を統合して詳しく説明する（v4.0） **旧【4. 構文分析】は廃止し、その内容を「動詞型（この英文で価値の高いもの／VP 番号昇順）」の各項目に統合する。** 動詞型を挙げるだけで終わらせず、その動詞が作る文の **S・V・O・C・M の要素分解／修飾関係（前置・後置修飾・関係詞節・分詞句・前置詞句）／節構造（主節・従属節、等位・従属接続、接触節＝関係代名詞の省略）／倒置・省略・強調構文**を各項目に織り込んで説明を膨らませる。複文は主節・従属節それぞれの動詞型を挙げ、各動詞型の下でその節の要素分解と接続を示す。**構文分析を独立ブロックとして別立てにしない**（【3】の中で完結させる）。 #### 動詞型にカード化案を統合して詳しく説明する（v5.0） **旧【6. カード化案】は廃止し、その内容を「動詞型（この英文で価値の高いもの／VP 番号昇順）」の各項目に統合する。** 各動詞型の説明の末尾に、定着用のカード案を添える（②語法カード＝表：日本語の要件／裏：英語＋型番号、③例文カード＝本文の該当箇所の和文英訳／裏に型番号・時制・米式✓）。カードは各動詞型の直下に置き、**独立ブロックにしない**（【3】の中で完結させる）。型が多いときは価値の高い型に絞って計2〜3枚でよい。 #### 動詞型に副詞的語句・修飾関係を統合して詳しく説明する（v6.0） **「副詞的語句・接続・修飾関係」という独立項目は作らない。** 副詞・前置詞句・従属節・等位接続・関係詞による修飾は、**それが掛かる動詞の型の下**で説明する。動詞型の各項目に、次を織り込む。 **副詞的修飾語(M)**（時・場所・手段・目的・理由・様態・頻度・程度／前置詞句か副詞か従属節か）、**接続**（and/or/but の等位、when/because/so that/while/if の従属が主節とどう繋がるか）、**関係詞による修飾**（先行詞は何か、制限用法か非制限用法か、接触節＝関係代名詞の省略）、**準動詞の修飾**（不定詞・分詞句・動名詞句がどこに掛かるか）を、各動詞型の項目に織り込む。複数の型にまたがる要素（文頭の前置き句など）は**最も関係の深い動詞型**で扱い、どの型にも属さない文修飾だけは列挙の後に1〜2行で簡潔に添える（見出し項目は立てない）。 #### 型番号の特定（必須手順） **VP / NP / AP の番号を書く前に、必ず `references/hornby-patterns.md` を読むこと。** そこに VP1〜VP25、NP1〜NP3、AP1〜AP3 の全型定義と原典の例文が入っている。番号は**記憶や推測で書かず、必ずこの表から選ぶ**。表にない番号を創作してはいけない（もっともらしい誤った番号は学習の土台を壊すため）。 出力形式： ``` - **動詞型 [VP17A]**: 主語＋他動詞＋名詞／代名詞＋(not)＋to不定詞（句） → 該当箇所: "asked us to submit" → 同型の例: Do you want me to stay? ``` **枝番（A/B/C）まで特定する。** 区別が曖昧なときは候補を複数挙げ、判断の根拠を示す。断定して誤るより、判断材料を示すほうが学習になる。 **動詞型は必ず VP 番号の昇順にソートして列挙する（v3.6・必須）。** 【3】の「動詞型（この英文で価値の高いもの）」を出力するとき、**列挙の順序は VP1 → VP25 の昇順**に固定する。「価値の高いものを選ぶ」場合でも、**選んだ結果を昇順に並べ替えてから書く**（重要度順・登場順で並べない）。同一番号内に枝番があるときは **A → B → C → D → E** の順にする。 - 並べ替えの規準：まず数字部分（1〜25）で昇順、同数字なら枝番（A〜E）で昇順。 - 例：`VP3A` → `VP6A` → `VP6E` → `VP8` → `VP9` → `VP14` → `VP18B` → `VP20`（この順で書く。VP20 を先頭に置いたり、登場順に並べたりしない）。 - VP6A のように**多数の該当箇所を1項目にまとめる**場合も、その項目自体は自分の番号（6A）の位置に置く。 - **出力前の自己点検**：動詞型の各項目の番号を上から読み、数字が単調増加（同数字は枝番が A→E）になっているかを確認する。崩れていれば並べ替える。 この規則は**動詞型（VP）の列挙順序**についてのものであり、各項目に添える「該当箇所」「同型の例」の書き方（上記出力形式）は変更しない。 特に **AP1** は見た目が同じ「形容詞＋to不定詞」でも A〜E で意味構造がまったく違うので、書き換え文で判別する（詳細は参照ファイル）。 #### 時制の特定（必須手順） **「時と時制」を書く前に、必ず `references/hornby-tenses.md` を読むこと。** そこに動詞 write の活用変化にもとづく**12時制**（単純現在1／現在進行2／単純過去3／過去進行4／未来5／未来進行6／現在完了7／現在完了進行8／過去完了9／過去完了進行10／未来完了11／未来完了進行12）の全定義が入っている。 入力英文の述語動詞を、**必ず番号（1〜12）と時制名で特定する**。表にない時制名を創作しない。複文の場合は**主節・従属節それぞれ**の時制を特定する。 出力形式： ``` - **時と時制**: [7] 現在完了時制非進行（Present Perfect Tense Non-Progressive） → 該当箇所: "has written" → write の活用: He has written → ある時点までの完了・結果に焦点。過去の一点ではなく現在との関連を示す。 ``` **12時制の枠外の形に注意。** 法助動詞（can / may / must / should / would）を伴う形、受動態、命令形、準動詞（不定詞・分詞・動名詞）は12時制の表に**含まれない**。無理に番号を当てはめず、「12時制のどれにも該当しない（法助動詞を伴う形）」と正直に書き、法（モダリティ）として説明する。受動態は「時制＋受動態」の組み合わせとして記述する。 **shall について**：原典は英国式に従い一人称の未来に shall を用いるが、**現代アメリカ英語（TOEIC＝ETS）では一人称でも will が標準**。原典の体系を示しつつ、実用形は will である旨を添える。 #### 章節番号（§）の扱い 一方、**章節番号（§4.4 など）は原典を参照できないため、推測で書かない。** 型番号とは扱いが違う点に注意。**確実でない場合は、参照ポインタの行そのものを出力しない**（v3.7）。`§___` のような空欄プレースホルダは**表示しない**。**§番号が確実なとき（例：会話でユーザーが教えてくれた対応）だけ**、「参照ポインタ: §4.4」の形で1行添える。 会話の中でユーザーが章節番号を教えてくれた場合（例：中位副詞の位置＝§4.4）、それ以降の出力ではその対応を使う。 ### 【4. 語彙・語法メモ】 重要語の意味・品詞・コロケーションを挙げる。TOEIC頻出語であればその旨を付記する。 **英式スペルが含まれる場合は必ず米式に変換して明示する**（例：labour → labor、centre → center、organise → organize、defence → defense、catalogue → catalog、travelled → traveled）。Hornbyはイギリス人の著作なので英式表記が多いが、TOEIC（ETS）は米式表記であり、学習者は出力を米式で統一する方針を取っている。 ### 【5. 全訳】 自然で読みやすい日本語訳。直訳調にしない。 ### 【6. 技術的背景と実践的価値（Anthropic エコシステム解説）】 **目的**：単なる翻訳を超えて、その機能のアーキテクチャ設計の思想と実践的な価値を深掘りする。 **書式**：テーマを要約する導入文を置いたあと、具体的なインサイトを丸数字（①、②…）を用いた見出しで分類し、それぞれ詳細を解説する。 入力英文がAnthropic製品（Claude Code、Agent SDK、MCP、フック機能など）の技術文書でない場合（TOEIC教材、ニュース記事など）は、このブロックを**その英文の背景・実務的意味の解説**に読み替える。 ### 【7. 🔗 実装に関連する公式ドキュメント等のソース情報】 **目的**：入力英文のトピック（CLIコマンド、Agent SDK、フック機能など）に最も関連性の高い、詳細な特定ページの**公式ドキュメント（docs サイト）**への確実なアクセスを提供する。 **⚠️ 【9】との役割分担（v8.2・必須）**：**このブロックは公式ドキュメント専用である。`anthropics/skills` リポジトリと、その中の個別スキル（mcp-builder / skill-creator 等）は【9. 関連する公式スキルの推奨】の管轄なので、【7】には挙げない。** 両ブロックとも Academy のときだけ出力されるため、分けないと同じ GitHub リンクが二重掲載される（実際に起きた）。【7】＝ドキュメントを読ませる、【9】＝動く実装を使わせる、と役割で切り分ける。 **ルール**： 1. 汎用的なトップページへの逃げを禁止する。該当機能が記述されている**正確なパス（ディープリンク）** を特定して提示する。 2. **リンク記法と生 URL 文字列を必ず並記する（v8.3・必須）。** リンクだけだと、プレーンテキストへのコピーや NotebookLM への取り込みなどリンクが機能しない環境で URL が失われる。生 URL だけだとクリックできない。**両方出して初めて、どの環境でも辿れる。** **書式（v8.3）**：各参照を次の2行1組で書く。番号を振って複数並べる。 ``` 1. **その参照が何か（英文のどの箇所に対応するか）** — [ページ固有の具体的なタイトル](https://...) URL: https://... ``` **URL 表記の禁止事項（v8.3）**： - ❌ **リンク記法だけで生 URL を省く**（コピー先で URL が消える） - ❌ **生 URL だけでリンクにしない**（クリックできない） - ❌ **URL をバッククォートで囲むコード表記**（クリックできなくなる。【9】と同じ原則） **出力前の自己点検**：【7】の各参照について、(1) リンク記法になっているか、(2) その直下に生 URL 文字列があるか、(3) バッククォートで囲っていないか、を1件ずつ確認する。 **URLの正確性について**：存在しないURLを創作してはいけない。ウェブ検索が使える場面では実際に検索して現存するURLを確認したうえで提示する。検索できず確実でない場合は、その旨を明記する。技術文書でない英文の場合は、該当する公式ドキュメントが存在しない旨を明記する（無理にURLをひねり出さない）。 --- #### 深掘りの方針（v3.3 で追加） **「そのページのトップ URL を1本出して終わり」にしない。** 入力英文が扱っている具体的な事項ごとに、**下記の5階層を意識して、可能な限り深い層まで掘る**。 **探索の階層**： | 層 | 何を出すか | 例 | |---|---|---| | **① 出典そのもの** | 入力英文が載っているページと、**その中のセクション** | `.../en/skills` の `Bundled skills` セクション | | **② 同一事項の一次情報** | 英文が言及している機能の、**定義や仕様が書かれた別ページ** | `/verify` が言及されたら、コマンドリファレンス | | **③ 一段深い仕様** | 設定スキーマ、CLI フラグ、JSON 形式、イベント一覧など**網羅的な参照資料** | hooks-guide に対する Hooks reference | | **④ 隣接する規格・外部仕様** | Anthropic 以外の一次情報（プロトコル仕様、標準規格） | MCP の話題なら Model Context Protocol の仕様サイト | | **⑤ 教材・実装例** | 該当トピックを扱う Academy コースの**特定レッスン**、Cookbook（**`anthropics/skills` は除く。【9】の管轄**） | Agent SDK の話題ならその上級コース | **本文中で名指しされた固有名詞は、原則すべて拾う。** コマンド名（`/verify`、`claude mcp add`）、設定キー（`disableBundledSkills`）、環境変数、プラグイン名、リポジトリ名（`anthropics/claude-plugins-official`）、参照先ページ名（`see the Hooks reference`）——**英文がそれを挙げたということは、読者がそこへ辿れる必要があるということ**である。 **各リンクには、そのリンクが英文のどの箇所に対応するかを一言添える。** 「なぜこれを挙げたか」が分からないリンクの羅列は、価値が薄い。 **目安**：技術文書なら**3〜7本**。1本しか出せない場合は、**深掘りが足りていないことを疑う**。ただし、英文が短く言及事項が少ない場合に無理に水増しはしない。 --- #### ⚠️ 深掘りにおける最重要の禁止事項 **URL を推測で組み立ててはならない。** これは型番号を推測で書かないのと同じ原則である。 - ❌ **セクションアンカーの捏造**：`.../en/hooks#posttooluse` のような `#アンカー` は、**実際に確認していない限り書かない**。ページ内の見出し名から機械的に生成すると、実在しない URL になりうる。 - ❌ **パスの類推**：`/en/skills` があるから `/en/skills/bundled` もあるはずだ、という推測。 - ❌ **バージョン付き URL の捏造**：`/v2/...` のような、見たことのない階層。 **取りうる手段は3つ**： 1. **ウェブ検索が使える場面**：`web_search` で実在を確認し、必要なら `web_fetch` でページ内のセクション構成まで見て、確実な URL を出す。**深掘りを求められている以上、検索を使える状況なら使う。** 2. **検索が使えない場面**：**既知の確実なページ URL のみを挙げ、その中の「どのセクションか」は日本語の説明で示す。** 例——「`https://code.claude.com/docs/en/hooks` の、PostToolUse イベントの項」。**アンカー付き URL にしない。** 3. **確認できない場合**：「該当ページはあるはずだが URL 未確認」と正直に書く。**空欄や省略より、未確認の明示のほうが価値がある。** **この3手段のどれを取ったかは、明示しなくてよい**（出力が煩雑になるため）。ただし**未確認のものには必ず印を付ける**。 --- #### 出力するかどうかの判定（v2.4 の規定を v3.4 で厳格化） **このブロックは、ソース区分が Anthropic Academy のときのみ出力する。それ以外のときは、見出しごと完全に省略する。例外はない。** | ソース区分 | 【7】を出力するか | |---|---| | **Anthropic Academy** | **○ 出力する** | | Claude Code Docs | **✗ 見出しごと省略** | | その他の公式ドキュメント（Claude Platform 等） | **✗ 見出しごと省略** | | 公式ドキュメント以外（TOEIC 教材・ニュース等） | **✗ 見出しごと省略** | **区分の判定は【1】の基準に従う**（`lesson` / `course` 等の**学習単位への言及**があれば Academy＝【7】を出力。**二人称だけでは Academy と判定しない**。迷ったら Docs＝省略）。**理由**：Claude Code Docs 等は出典自体が公式ドキュメントでリンク再掲の価値が薄いが、Academy 教材は「概念の説明」であり、**対応する実装ドキュメントへの橋渡し**が学習上の価値を持つ。 **次の理由で例外を作ってはならない**： - ❌ **英文が他ページを名指し参照しているから**（`see the Hooks reference` など）→ **出力しない。** 参照先は【6】の解説内で言及すれば足りる。 - ❌ **英文が固有名詞（コマンド名・環境変数・機能名）を多く含むから** → **出力しない。** - ❌ **深掘りの規定を追加したので、その効果を見せたいから** → **出力しない。** これは学習者の設計ではなく、出力する側の都合である。 - ❌ **リンクを出したほうが親切に見えるから** → **出力しない。** 学習者は Academy のときだけこのブロックを求めている。 **Academy 以外で参照先を示したい場合**：【6. 技術的背景と実践的価値】の本文中で、**日本語の説明として**言及する（「詳細は Hooks reference のページにある」など）。**【7】の見出しを立ててはならない。** **この判定は、深掘りの方針（下記）よりも優先される。** どれほど深く掘れる英文であっても、**Academy でなければ出力しない。** ## 出力例（抜粋） **Input:** The manager asked us to submit the report by Friday. **Output（【3. 英語の型と語法】ブロックのみ抜粋）:** ```markdown ## 【3. 英語の型と語法】 - **動詞型 [VP17A]**: 主語＋他動詞＋名詞／代名詞＋(not)＋to不定詞（句） → 該当箇所: "asked us to submit" → 同型の例: Do you want me to stay? → ask/want/wish はこの型を取る。ask + O + that節は不可。 → 構文: The manager(S) asked(V) us(O) to submit the report(to不定詞句＝O の補文) by Friday(M・期限)。単文で従属節なし。 → カード: 〔②語法カード〕表「（人）に…するよう頼む」→ 裏 asked us to submit（VP17A・to不定詞を目的補語に取る）／米式✓ → 修飾: 前置詞句 by Friday が submit に掛かる期限の副詞的修飾語(M)。until ではなく by（期限＝完了時点）である点に注意。従属節・関係詞は無し。 - **時と時制**: [3] 単純過去時制（Simple Past Tense） → 該当箇所: "asked" → write の活用: He wrote → 要請の時点が過去の一点に固定されている。 - **名詞型 [NP] / 形容詞型 [AP]**: 該当なし - **概念の表し方**: 「要請」に該当。ask + O + to do は依頼・要請の標準形。 ``` ### 【9. 関連する公式スキルの推奨】 #### 出力判定（v8.0・【7】と同じ論理） **ソース区分が Anthropic Academy のときのみ出力する。Claude Code Docs・Claude Platform Docs・その他の公式ドキュメント・公式以外（TOEIC 教材等）では、見出しごと完全に省略する。例外はない。** 区分の判定は【1】の基準に従う（`lesson` / `course` 等の**学習単位への言及**があれば Academy。**二人称だけでは判定しない**。迷ったら Docs＝省略）。**理由**：Docs 系はそれ自体が実装リファレンスで別実装への橋渡し価値が薄いが、Academy は概念・教材なので**概念から動く実装への橋渡し**が学習価値を持つ（【7】とまったく同じ非対称性）。 **目的**：Academy で学んだ概念を、実際に動く公式実装へ橋渡しする。CCAR-F は実務的判断を問うので、概念（英文）と実装（スキル）の往復が有効。 **必須手順**：**選ぶ前に必ず `references/anthropic-skills-catalog.md` を読む。** `anthropics/skills` 全17ディレクトリの概要・効く Domain・確認済み URL が表で入っている。スキル名と URL は**記憶や推測で書かず必ずこの表から選ぶ**（型番号と同じ原則）。英文の主題とカタログの Domain 対応を突き合わせ、**1〜3件に絞る**（網羅列挙しない）。**【8】で「0本」と判定した Domain に効くスキルを優先**。該当が薄い英文では「直接対応するスキルなし」と1行で終える。 **出力形式**： ``` **1. mcp-builder** — https://github.com/anthropics/skills/tree/main/skills/mcp-builder - 概要: MCP サーバーの設計・実装・評価を導くスキル。 - この英文との繋がり: 本文が扱う MCP サーバー登録の「次の段階」（自分で作る側）にあたる。 - 効く Domain: Domain 2（Tool Design & MCP Integration・18%）。 ``` **URL の扱い**：カタログの URL を使い、**表にないパスを推測で組み立てない**。**URL は必ずリンクとして機能する形で出力する**（生 URL をそのまま書くか `[スキル名](URL)` のリンク記法。**バッククォートのコード表記にしない**——クリックできなくなるため）。`docx`/`pdf`/`pptx`/`xlsx` は source-available（Apache 2.0 ではない）ため、改変・再配布を伴う文脈ではその旨を添える。 ### 【8. CCAR-F 試験範囲との対応】 **目的**：読んだ英文が、CCAR-F 試験のどの範囲に当たるのかを対応づけ、「この英文を読むことが試験対策としてどう効くか」を可視化する。学習の網羅性と偏りを、学習者自身が把握できるようにするため。 **このブロックを書く前に、必ず次の2つを読むこと。** - `references/ccar-f-blueprint.md` — ドメイン番号・配点・タスクステートメント番号・シナリオ番号。**記憶や推測で書かず、必ずこの表から選ぶ**。表にない番号を創作してはいけない（型番号と同じ原則）。 - `references/ccar-f-keywords.md`（v9.0 追加） — 試験に出る技術用語一覧・In-Scope / Out-of-Scope 論点・公式が名指しするアンチパターン・判断の3軸。 **書き方**： ``` ## 【8. CCAR-F 試験範囲との対応】 **対応ドメイン**: Domain 3 — Claude Code Configuration & Workflows（配点 20%） **タスクステートメント**: 3.2 カスタムスラッシュコマンドとスキルの作成・設定 **関連シナリオ**: シナリオ2「Code Generation with Claude Code」 **出題される場合の問われ方**: 「チーム全員に共有したいコマンドをどこに置くか」のような配置場所の判断、 または「スキルと CLAUDE.md のどちらを使うか」の使い分けとして問われうる。 判断の軸は「常時適用か、オンデマンドか」。 ``` **対応づけの原則**： 1. **無理に当てはめない。** 該当が薄い場合は「直接の該当なし。ただし Domain X の背景知識として効く」と正直に書く。公式ドキュメント以外の英文（TOEIC教材・ニュース記事など）は「試験範囲外（英語力の補強が目的）」と明記する。 2. **配点比率を必ず添える。** 学習者が「今どの配点帯を勉強しているか」を把握できるようにするため。 3. **複数ドメインにまたがる場合は全て挙げる。** 例：スキルの `allowed-tools` は Domain 3（設定）と Domain 2（ツール分配）の両方に関わる。 4. **「出題される場合の問われ方」は、暗記ではなく判断の軸で書く。** 公式サンプル問題の正解は、次の3軸で決まっている（詳細は参照ファイル）。 - **確実性が要るか** → 要るならプログラム的強制（フック等）、要らないならプロンプト - **根本原因に当たっているか** → 症状ではなく原因を直す選択肢を選ぶ - **対処が問題に比例しているか** → 過剰設計（over-engineered）は誤答 5. **技術用語を照合する（v9.0・必須）。** 英文中に `references/ccar-f-keywords.md` §1 の技術用語（`stop_reason` / `tool_choice` / `Task tool` / `allowedTools` / `isError` / `context: fork` / `--resume` / `fork_session` / `custom_id` / `lost-in-the-middle` など）が現れたら、**その用語を明示して対応づける**。公式ガイドが名指しした用語は出題対象なので、英文で出会ったこと自体が学習価値になる。 6. **範囲外なら範囲外と書く（v9.0・必須）。** 同ファイル §3 の Out-of-Scope 論点（ファインチューニング、課金・認証、インフラ、Computer use、画像認識、ストリーミング、レート制限、トークナイズ等）を扱う英文では、**無理に対応づけず「公式ガイド §17 で明示的に試験範囲外」と書く**。範囲外と知ることも学習の一部である。 7. **アンチパターンに触れていたら指摘する（v9.0）。** 英文が同ファイル §4 のアンチパターン（自然言語でループ終了を判定、汎用エラー、ツールの与えすぎ、自己申告 confidence、感情分析での判断、自己レビュー等）に関係する場合、**「これは公式が名指しする誤答パターン」と明示する**。選択肢問題で誤答として現れやすいため、印象づける価値が高い。 **学習の偏りを検知したら知らせる**：Claude Code Docs（Domain 3）ばかりが続いている場合など、配点上の偏りに気づいたときは、このブロックの末尾で簡潔に指摘してよい。**Domain 1（エージェント設計・27%）が最大配点**である点に注意する。 ### 【10. 想定問題】（v10.0 で追加・条件付き） **出力条件**：【8】で試験範囲内と判定した英文のときだけ出力する。範囲外（`ccar-f-keywords.md` §3 の Out-of-Scope）・英語教材・一般記事では**見出しごと省略**する。 **目的**：CCAR-F は暗記ではなく判断を問う試験である。読んで理解するだけでは、本番の「**選択肢の中から選ぶ**」行為を一度も練習できない。理解と選択は別の能力なので、読んだ直後に1問解いて変換する。 **必須制約（自作問題が公式とずれないための歯止め）**： 1. **必ず公式サンプル問題の判断3軸のいずれかを軸に据える。** 軸のない問題（単なる用語の暗記確認）は作らない。作問後、「この問題はどの軸か」を自分で言えなければ作り直す。 - **確実性**：失敗が許されない場面か。要るならプログラム的強制（フック・前提条件ゲート）、要らないならプロンプト。 - **根本原因**：症状ではなく原因に当たっているか。下流が正常なら原因は上流の設計にある。 - **比例性**：対処が問題の規模に見合うか。過剰設計（分類器の訓練、大規模基盤）は誤答。 2. **正解の根拠は、読んだ英文か参照ファイルに書かれている事実に限る。** 推測で仕様を作らない。 3. **軸を出力に明記する。** どの軸の問題かを示すことで、学習者が公式問題と照合できる。 4. **シナリオ・設問・選択肢は英語で書く（v10.2・必須）。** 本番は英語で出題される。日本語で判断だけ練習しても、**英語の長いシナリオを読んで状況を把握する負荷**が再現できない。公式サンプル問題と同じ語彙・言い回し（`Production data shows that ...` / `What change would most effectively address ...` / `What's the most effective first step ...`）を使う。 5. **出題した英文を教材として解説する（v10.3・必須）。** 正解と誤答の理由（日本語）を書いた後に、**Scenario・Question・選択肢A〜D のすべて**を対象として【スラッシュリーディング】【英語の型と語法】【語彙・語法メモ】【全訳】の4ブロックを追記する。出題文は試験特有の言い回しの塊なので、それ自体が読解教材になる。 **選択肢A〜Dも必ず解説対象に含める（v10.3）。** v10.2 では「分量が多いため」選択肢を除外していたが、これは誤りだった。理由は2つある。 - **本番で最も時間をかけて読むのは選択肢である。** 4つを比較して1つを選ぶため、シナリオより読む語数が多い。 - **誤答の選択肢は「一見もっともらしい」ように作られており、語法の微妙な差が判断を左右する。** 例：`keeping the Bedrock deployment` という付帯状況の分詞句が「既存を維持したまま」を含意する、`replicates ~ functionality` が自前再実装を意味する、など。解説から外すと、実際に判断を要する箇所が教材にならない。 **【全訳】を追加する（v10.3）。** Scenario・Question・選択肢A〜D の日本語訳を並べる。**4択の訳を並置すると選択肢間の差分が見えやすくなり**、なぜ1つだけが正解なのかが構造的に理解できる。 **誤答の作り方・公式12問の分析・作問チェックリスト**：`references/question-design.md` を読むこと。公式の誤答は「明らかに変な選択肢」ではなく**一見もっともらしいが軸を外している**もので構成される。その型（プロンプトで済ませる／過剰設計／症状に対処／存在しない機能／別の問題を解いている）が同ファイルにある。 **出力形式（v10.2）**： ``` ## 【10. 想定問題】 **判断軸**: 比例性（対処が問題の規模に見合うか） **Scenario**: <英語で1〜3行。公式同様、具体的な数値・症状を含める> **Question**: <英語で1文。What / Which を使った問い> A. <英語の選択肢> B. <英語の選択肢> C. <英語の選択肢> D. <英語の選択肢> **正解**: X。<日本語で、なぜ正しいかを軸に沿って説明> **誤答の理由**: A は…／B は…／D は…（日本語） --- ### 出題文の解説 **【スラッシュリーディング】** **【英語の型と語法】** <動詞型を VP 番号昇順で。構文・修飾関係・カード案を各項目に統合（【3】と同じ方針）> **【語彙・語法メモ】** <試験特有の言い回しを中心に。選択肢に現れる語法（付帯状況の分詞、動詞の含意など）も含める。米式スペルの確認も行う> **【全訳】** ``` **1問だけ作る。** 複数出すと解く負荷が上がり、読解の流れが切れる。英文が薄く問題を作れない場合は、無理に作らず「この英文からは判断を問う問題を作れない（定義・用語の紹介に留まるため）」と1行書いて終える。 ## 参照ファイル **【3. 英語の型と語法】を書く前に、以下を必ず読む。** - `references/hornby-patterns.md` — VP1〜VP25 / NP1〜NP3 / AP1〜AP3 の全型定義と原典例文 - `references/hornby-tenses.md` — 12時制の全定義（動詞 write の活用変化）と相の意味 - `references/ccar-f-keywords.md` — **【8】用**。試験に出る技術用語一覧・In-Scope / Out-of-Scope 論点・公式が名指しするアンチパターン・判断の3軸（v9.0） - `references/anthropic-skills-catalog.md` — **【9】用**。`anthropics/skills` 全17ディレクトリの概要・効く Domain・確認済み URL（v7.0） - `references/question-design.md` — **【10】用**。判断3軸・誤答の型・公式12問の分析・作問チェックリスト（v10.0） - `references/changelog-archive.md` — v3.4 以前の変更履歴（当時の番号体系のまま） > **`references/hornby-noun-modifiers.md`（§3.81〜§3.84）は v3.5 で必読から外した。** 名詞の形容詞的用法・分詞形容詞の解説は行わない方針になったため、このファイルは**読まない**。ファイル自体はディスク上に残してあるが（後戻りのため）、出力では参照しない。 **【8. CCAR-F 試験範囲との対応】を書く前に、以下を必ず読む。** - `references/ccar-f-blueprint.md` — CCAR-F の基本情報、5ドメインと配点比率、全タスクステートメント、6シナリオ、公式サンプル問題から読み取れる出題パターン、公式が挙げる準備方法 この分離は段階的開示のため。型定義表・時制表・試験ブループリントは毎回のコンテキストに常駐させる必要はなく、型や時制を特定するとき、試験範囲を対応づけるときにだけ読めばよい。 ### §3.81〜§3.84 の解説はしない（v3.5 の方針） `event-driven`（分詞形容詞）や `tool calls`（名詞＋名詞）のような、VP/NP/AP のいずれにも該当しない現象について、**ホーンビー第3章 §3.81〜§3.84（名詞の形容詞的用法・分詞形容詞）を持ち出して解説してはならない。** - ❌ **【4. 語彙・語法メモ】に §3.81〜§3.84 の節番号を添えて記録する** → しない - ❌ **名詞＋名詞・分詞形容詞・物質名詞 vs -y/-en 形容詞を §番号で特定する** → しない - ❌ **`references/hornby-noun-modifiers.md` を読んで節番号を引く** → しない（このファイルは参照しない） これらの現象に触れる必要がある場合は、**§番号を伴わない通常の語法メモ**として【4】で簡潔に扱えばよい（例：「event-driven は『イベント駆動の』という複合形容詞」）。**§3.81〜§3.84 という節番号の明示・解説は出力しない。** **背景（v3.1 → v3.5 の経緯）**：v3.1 で「『型の枠外』で済ませない」方針として、これらの現象を §3.81〜§3.84 の節番号で特定し記録する規定を追加した。v3.5 では学習者の要求によりこの解説を取りやめた。**v3.1 で追加した参照ファイル `references/hornby-noun-modifiers.md` はディスク上に保持している**（後戻りのため）が、出力では使わない。 ## 運用上の注意 このフォーマットは学習用であり、**網羅より定着**を優先する。ブロックが多いので冗長になりがちだが、各ブロックは簡潔に書く。特に【1】〜【5】が学習の本体で、【6】【7】は技術文書のときに真価を発揮する補助ブロック。**【8】は CCAR-F 受験対策としての位置づけを示すブロック**で、Anthropic の公式ドキュメント・教材を読んだときに機能する（試験と無関係な英文では「試験範囲外」と一行書けばよい）。 学習者は「金フレなしでWeblio＋Hornbyで進める」方針を取っており、米式スペルの統一と、カードによる毎日の想起（テスト効果・間隔反復）を軸にしている。出力はその運用に乗る形にする。