Generate a fictional, full-length introductory book (入門書) on a requested topic for the user to read as a deep study method. The deliverable must match the length AND density of a real bookstore primer — 100,000〜150,000字 with each section dense in specifics (real names, numbers, dated events). Use this skill whenever the user asks to write a 本 / 入門書 / 教科書 / primer / textbook on a topic, or asks for book-format study material. Strongly prefer this skill over a Q&A summary when the user wants to LEARN by reading. This skill REQUIRES web_search for any topic involving current facts (pricing, versions, releases, specs, company news) before writing — guessed facts and ungrounded aphorisms break the book.
架空の入門書をAIに書いてもらい「自分が読む」ことで学ぶ手法。要約より「本」のほうが頭に残る理由:
ターゲットは「書店で売っている入門書と同等の 密度」。総字数だけ稼いだ「ジェネリック格言集」はNG。LLM特有の「薄く引き延ばした要約」を防ぐため、構成の再帰的分割と、末端単位での反復執筆を徹底する。
書き始める前に Web 検索で素材を集める。ただし メインエージェントで直接検索すると、生の検索結果がコンテキストを食い尽くし、執筆フェーズで context window が枯渇する。必ず リサーチ専用のサブエージェントに委任すること。
Agent ツールで general-purpose(または Explore)サブエージェントを 1回起動outputs/[トピック]_素材ノート.md に保存サブエージェントには 本文を書かせない。素材収集のみ。書かせると密度・文体ルール(著者の声、格言禁止)が一切効かないため。
あなたは入門書執筆のためのリサーチ専門エージェントです。本文は書かず、素材だけを集めて構造化して返してください。
トピック: [トピック名]
切り口/角度: [サブタイトル候補や問題意識]
以下の観点で 8〜15 回の web_search を実行し、結果を「素材ノート」として返してください。
検索カテゴリ:
- 全体像と歴史(例: `[トピック] 歴史 推移`)
- 現在のプレイヤー名と数字(例: `[トピック] 主要企業 売上 2025`)
- 直近の事件・ニュース(例: `[トピック] 失敗事例 炎上 事件`)
- 業界の批判・限界論(例: `[トピック] 批判 限界 問題点`)
- 規格・契約・法令の実例(該当する場合)
- 業界人の発言・著作(例: `[名前] 発言 インタビュー`)
返却フォーマット(これに厳密に従う):
## 素材ノート: [トピック]
### 固有名詞(企業・製品・規格・人名・事件名)
- (20個以上)
### 具体的な数字・日付
- YYYY年MM月: xxx
- xxx は ◯◯円/◯◯人/◯◯%
- (15個以上)
### 事件・ケーススタディ
- [事件名・年]: 概要、登場人物、含意
- (5件以上)
### 引用しやすい発言
- [人物名・所属・年]: 「発言内容」(出典 URL)
- (5件以上)
### 業界の批判・対立軸
- [論点]: 誰が誰に何を言っているか
- (3件以上)
### 推奨される章立てのヒント
- (この素材から組み立てるなら、どういう章が立てやすいか 5〜8案)
繰り返し: 本文の執筆はしないでください。素材ノートのみ返却してください。検索結果の生テキストを長々貼り付けるのも禁止。要点だけを上記フォーマットに圧縮してください。
各節を書く時は 素材ノートから 固有名詞・数字・引用を最低 1つ拾って本文に登場させる。素材ノートに登場している人名・企業名・事件名は、本全体で繰り返し参照することで読後の記憶定着を狙う。
逆に 素材ノートに無い固有名詞・数字を勝手に書くのは禁止(推測になるため)。必要なら追加リサーチを依頼するか、抽象表現で逃げる。
古典的理論のみ(古典力学、形式言語理論、江戸時代史など)。この場合 Phase 1 はスキップして直接 Phase 2 へ。
価格・バージョン・統計・日付・人名は素材ノートで確認するか、書くのを諦めて抽象表現で逃げる。「2024年頃」「数十億円規模」のようなぼかしは許容、確定的な数字の捏造は失格。
LLMの出力制限による「サボり」を防ぐため、目次をツリー状に極限まで細分化する。
この「章→節→項」のツリー構造(本全体の設計図)をユーザーに提示し、合意を取ってから本文へ進む。「任せる」と言われたら即進行。
Codex で見出しと本文の日本語を詰めるときは、references/codex-japanese-style.md を参照してから章タイトルと節タイトルを作る。
絶対に全章や「複数章」を1ターンで書いてはいけない(内容が極めて薄くなるため)。 章単位ではなく、「節(Section)」を執筆の最小単位として、少しずつループ(反復)で書き進める。
Edit ツールでファイルに追記する。1ターンあたり最大でも 1〜2節(合計 3,000〜5,000字程度)まで。それ以上を狙うと途端に密度が落ちる。前の節の文脈を踏まえ、重複を避けて滑らかに繋ぐこと。
「1〜2節まで」をお願いベースで書いても、モデルによっては平気で全章を書こうとする(特に Codex / Gemini)。以下を機械的なカウントとして守ること。
### N.X の見出しは 最大 2個。書き始める前に「今回書く見出しは N.X と N.Y の2個」と宣言してから本文に入る全章書き終わったら、後述のセルフチェック全項目に通るか確認。事実関係に不安があれば再度検索。
最終ファイルを outputs/ に保存し、保存先の相対パスをユーザーに伝える。
# [トピック]入門
## 【第N版】
[サブタイトル: 固有名詞 1〜3個 + 切り口1フレーズ]
[著者名(絵文字1つ)]
YYYY年MM月 第N版
## 第N章: [章タイトル] — [副題]
[章の導入。具体的なシーン・人物・事件から入る。1〜2段落、400〜600字]
### N.1 [節タイトル]
[本文 1,500字以上、3〜6段落。後述の節密度ルール]
### N.2 [節タイトル]
[同上]
### N.3 [節タイトル]
[同上]
#### ■コラム [コラム題]
[3〜6段落、800字以上、具体的事例を含む]
### N.4 [節タイトル]
[同上]
[章末の総括。100〜200字]
各章の目標は 8,000〜12,000字、節 3〜5個。
### N.X の各節は以下を満たさないとダメ:
置換テスト: 節を読んだとき、別のトピック(DX、業務改革、組織論など)に置き換えても成立してしまう文章は失格。具体性が無い証拠なので書き直す。
各章は次の最低数を満たすこと:
満たないなら検索して追加するか、章を削る。
1本あたり 800字以上、3〜6段落。1段落で終わるコラムは「形だけ」とみなされる。
ネタは: 歴史的経緯、命名の裏話、業界の逸話・事件、規格化の裏側、失敗事例・炎上事件。
本全体で 5〜10本。10章ならコラム無しの章があってはならない。
| 版 | 総字数 | 章数 | 1章あたり | 執筆の進め方 |
|---|---|---|---|---|
| 簡易版 | 30,000〜50,000字 | 6〜8章 | 4,000〜6,000字 | 1ターンに1章ずつ |
| 標準 | 100,000〜150,000字 | 10〜12章 | 8,000〜12,000字 | 1ターンに1〜2節ずつ |
| 本格版 | 150,000〜200,000字 | 12〜15章 | 10,000〜15,000字 | 1ターンに1節ずつ |
章数を増やして総字数を稼ぐのは禁止。1回の実行単位を極小化し、1節ごとの記述を深掘りすることで密度と規模を両立する。
Codex で日本語の質感をさらに詰める必要がある場合のみ、references/codex-japanese-style.md の補助ルールを追加で使う。
「散文で書け」「著者の立場を表明せよ」と書かれても、参考文が無いとモデルは無難な解説調に倒れる(特に Codex / Gemini)。以下を語り口の基準として参照すること。本文を書く前にこのサンプル群をもう一度読み、トーンを合わせてから書き始める。
サンプル1(評価を含めて切り込む):
筆者は、2023年の生成AIブームを「第三次AIブーム」と呼ぶことに違和感を持っている。前二回が研究室発の波だったのに対し、今回は最初から SaaS の課金モデルに乗って広がった点で性質が違う。OpenAI が ChatGPT Plus を月20ドルで売り出した瞬間、これは技術史ではなく流通史の話になったのだ。
サンプル2(業界の建前を疑う):
多くの SIer が「AI 内製化支援」という看板を掲げている。だが私見では、この言葉はかなり怪しい。内製化を本気で支援すれば自社の受注は減るはずである。にもかかわらず売上が伸びているなら、それは内製化「ごっこ」を売っているか、別の何かを抱き合わせているかのどちらかだろう。
サンプル3(自分の解釈を提示する):
NTTデータが2024年に発表した「LITRON」は、日本語特化LLMの一つとして語られることが多い。しかし筆者は、これを技術製品としてではなく「金融・公共向けに説明可能性を担保した提案ツール」として読むのが正確だと考えている。実際、初期ユースケースの大半は議事録要約と稟議書ドラフトに集中していた。
サンプル4(読者への目配せ):
ここで読者の中には「PoC で終わるのは AI に限った話ではない」と感じる方もいるだろう。その通りで、CRM 導入も BI 導入も同じ問題を抱えてきた。だが本書がこの章を割くのは、生成AIが他の技術より「PoC を生みやすい」構造的な理由を持っているからだ。それは次節で述べる。
サンプル5(歴史を引いて現在を相対化する):
1990年代後半の ERP ブームを覚えている読者なら、いま起きていることに既視感を抱くはずだ。当時も「業務をパッケージに合わせる」という掛け声のもと、各社が SAP R/3 の導入に走った。結果として残ったのは、カスタマイズで原型を留めない巨大なモノリスだった。生成AI 導入の議論は、この記憶を踏まえずに進めるべきではない。
共通する型:
体言止めの格言・抽象的な総括は ビジネス書の悪い癖。1章につき多くて1個まで。
過去にこのスキルが出してしまった、または他モデル(特に Codex / Gemini)で頻出する型。本文中に出たら 即・書き直し。
「Xは○○ではなく△△だ」型
「重要なのは○○である」型
「我々が学ぶべきは○○だ」型
「真の○○とは」型
「単なる○○ではない」型
「○○の本質は」型
AI的前置き型
安全な丸め型(出典なしの逃げ)
形容詞積み増し型
ふんわり総括型
二項対立の安直な提示型
比喩の言いっぱなし型
これらは全て、別のトピック(DX、業務改革、組織論、人材育成、サステナビリティ…)にそのまま貼り付けても成立してしまう。これが「中身が無い」の正体である。置換テストに落ちる文章はすべてこの仲間。
富士通の時田社長は2024年度の決算説明会で「Uvanceは累計受注高2,000億円を超えた」と述べた。Uvanceは業種別ソリューション群の総称で、生成AIはその中の一つの売り方として位置付けられている。これは「個別案件の積み上げで売る」発想から「型を売る」発想への転換を示している。
固有名詞 + 数字 + 引用 + 含意の解説、という4点セット。NG パターンを書きそうになったら、この型に流し込めるか確認する。流し込めないなら 書かない(節を統合する、別の事例で書き直す)。
NG: 重要なのは技術ではなく、運用である。
書き直し: みずほ銀行の勘定系刷新(MINORI、2019年稼働)が示したのは、技術選定の良し悪し以上に「数千社規模のベンダーをどう束ねるか」という運用設計が成否を分けるという現実だった。本書がこの章で扱う生成AIプロジェクトも、構図は変わらない。
NG: 真の DX とは、文化の刷新である。
書き直し: 経済産業省が2018年に「DXレポート」で示した「2025年の崖」という言葉は、結果として技術論から組織論へ議論をスライドさせる役割を果たした。筆者はこの転換自体は妥当だったと考えるが、副作用として「文化を変える」という空疎な掛け声だけが残ってしまった面もある。
outputs/[トピック名]入門_第N版.md に保存--- を入れるpython .claude/skills/fictional-textbook/script/convert_to_pdf.py [Markdownのパス] を実行markdown2 ライブラリが未インストールの場合はインストール--epub フラグを付けて実行: python .claude/skills/fictional-textbook/script/convert_to_pdf.py --epub [Markdownのパス]ebook-convert に直接 .md を渡すと Mermaid が画像化されず素のコードブロックとして残るため必ずスクリプト経由で変換するC:\Program Files\Calibre2\ebook-convert.exe)が必要PDF 変換時、スクリプトは「ファイル冒頭から最初の --- まで」のテキストを扉メタデータとしてパースし、その範囲を丸ごと削除してからカバー画像オーバーレイを合成する。このため 表紙画像  は最初の --- より後ろ(本文側)に配置すること。冒頭の --- より前に置くと削除処理で img 自体が消え、PDF に表紙が出なくなる。
また、カバーオーバーレイの検出正規表現は alt が 表紙:(コロン付き)で始まる img のみにマッチする。 のようにコロンなしだと発動しない。
推奨の扉レイアウト:
# [タイトル]
## 【第N版】
[サブタイトル]
[著者名(絵文字1つ)]
YYYY年MM月 第N版
---
![表紙: [タイトル]](images/cover.png)
<!-- prompt: ... -->
## 目次
デフォルトでは挿絵を入れない。本文のみで完結させる。
ユーザーから明示的に以下のような指示があった場合のみ、本セクションのルールで挿絵を扱う。
判断に迷う指示なら、勝手に追加せず一度ユーザーに確認する。
挿絵を入れると決まったら、Phase 2(章立て)に入る前に まず script/check_config.ps1 を実行して実生成モードか fallback モード(プレースホルダのみ)かを確定させる。モードが決まらないと style 選択や命名規則の合意も進められないため、ここで分岐する。
「挿絵を入れて」と言われても、概念説明には図解(Mermaid 等)を使うこと。挿絵はあくまで雰囲気と記憶のフック。
最初に1つ選び、本全体で同じ style 句を全プロンプトに埋め込む。執筆開始時にユーザーに選んでもらうか、内容に合わせて以下から1つ提案する。
迷ったら A か B。技術書寄りなら C。
固定 style 句の例(B を選んだ場合):
soft watercolor wash with delicate ink line work, muted earth tones with one accent color (deep blue), slight paper texture, editorial book illustration, restrained and literary mood
これを毎プロンプトの末尾に必ず付ける(章ごとにスタイルを変えてはいけない)。
[Subject: 何が描かれているか、人物の概要・場所・行為]
[Composition: アングル/構図/視線誘導]
[Mood: 時間帯・光・空気感]
[固定 style 句]
[Negative: no text, no logos, no recognizable real people, no watermark]
[Size: 1536x1024 (章扉・横長) / 1024x1024 (本文挿絵・スクエア) / 1024x1536 (表紙・縦長)]
gpt-image-1.5 がサポートするのは上記3サイズのみ。16:9 / 4:3 / 2:3 のような一般的なアスペクト比表記は使わない(スクリプトが拒否するため)。
章扉(第1章「生成AIブームの正体」、style B):
A crowded train platform in Tokyo at morning rush hour, faceless commuters in business suits walking past, one figure in the foreground stopped and looking up at a blank advertisement panel symbolizing a hollow promise. Slight motion blur on commuters. No text, no logos, no recognizable real people. Soft watercolor wash with delicate ink line work, muted earth tones with one accent color (deep blue), editorial book illustration. Size 1536x1024.
比喩の視覚化(「PoC の罠」、style B):
A spiral staircase viewed from above that loops back to its own starting point, a single small figure climbing endlessly. Abstract architectural sketch feel. No text, no logos. Soft watercolor wash with delicate ink line work, muted earth tones with one accent color (deep blue), editorial book illustration. Size 1024x1024.
script/config.json が実キーに差し替わっている場合は、プレースホルダで止めずに script/generate_image.ps1 を呼び出して PNG を実生成する。プレースホルダ方式はキーが未設定のときの fallback。
手動で config.json の中身を読んで判定しない。必ず script/check_config.ps1 を呼び出し、その出力で分岐する。
powershell -ExecutionPolicy Bypass -File "script/check_config.ps1"
出力と exit code の対応:
CONFIGURED: OpenAI または CONFIGURED: Azure(exit 0) → 実生成モードへ進むNOT_CONFIGURED: <理由>(exit 1) → プレースホルダのみで止める(キー未設定)NOT_CONFIGURED: <理由>(exit 2) → config.json 欠損や JSON パース失敗。ユーザーに通知して指示を仰ぐ判定スクリプト自体はキーを漏らさない(Configured か NotConfigured かだけを返す)。キー本文を読みたくなっても、本スキルから直接 config.json を cat しない。
挿絵1枚ごとに PowerShell から以下を実行する(Windows 環境・bash シェルから呼ぶ場合)。-OutputPath で最終ファイル名まで直接指定するため、生成後のリネームや移動は不要。
powershell -ExecutionPolicy Bypass -File "script/generate_image.ps1" -Prompt "<英語プロンプト(固定 style 句を含む)>" -Size "<1024x1024|1024x1536|1536x1024>" -OutputPath "outputs/images/ch01_opener.png"
-Size は 1024x1024 / 1024x1536 / 1536x1024 の3種のみ-OutputPath は Markdown から参照するパス( なら outputs/images/ch01_opener.png)をそのまま渡す。親ディレクトリはスクリプトが自動作成images/ch[章番号]_[用途].png 形式で統一(例: cover.png, ch01_opener.png, ch03_column.png)generate_image.ps1 が API エラーや認証エラーで失敗した場合、そのコマの挿絵だけ プレースホルダ方式に戻す(全体の執筆は止めない)。ユーザーには「N枚中M枚は生成成功、残りはプロンプト埋め込みのみ」と明示する。
挿絵を入れる位置に、以下の形式でプレースホルダとプロンプトをセットで埋め込む。config.json が未設定なら画像ファイル本体は生成しない(プロンプトの埋め込みまでが本スキルの仕事)。設定済みなら上記「画像の実生成」手順で PNG を作り、 のリンク先に配置する。

<!--