ブログ記事レビュー

記事を読みました。内容そのもの（状態の外在化、制約の階層化、契約発見ループ）は具体的で面白いので、読みにくさの主因は情報量ではなく、言い回しの様式の反復と造語の密度にあります。冒頭でAI執筆を明言している記事なので、チックの体現はある程度意図的な自己例示かもしれませんが、読みやすさを優先するなら以下が効きます。体感で4〜5割は縮められるはずです。

1. 簡潔にする方法

結論の重複を一本化する。 第1節の見出し、冒頭の引用ブロック、末尾の引用ブロックは、いずれも「生成が可能性を広げ、工学が望ましい候補の残る条件を設計する」というほぼ同一の主張です。一番効く末尾に一度だけ置けば十分で、これだけで全体のくどさがかなり消えます。
表と本文の二重記述をやめる。 第3節の契約分類の表と第4節の制約8層の表は内容が大きく重なっており、統合できます。表のある箇所では本文の列挙を削り、代表例ひとつと含意だけ書く。第5節の失敗一覧も同様です。
造語を3つ程度に絞る。 「執筆契約」「確定正本」「文体予算」あたりを残し、被参照台帳・文体チック・寿命設計・根拠管理・執筆キット・検証債務台帳・思い返し装置などは普通の説明語に開く。読者が保持すべき定義が減るほど本文も自然に短くなります。
余談と重複図を切る。 会話ログを掘り起こす「執筆考古学」の段落は別記事にまとめると明言されているので1文の予告で足ります。CEGIS節のテキストフローは第5節の循環図とほぼ同じ内容なのでどちらかに。導入の書誌的経緯も3文程度に詰められます。

2. 文体の不自然な点と直し方

「AではなくB」型の頻発。 記事自身が「AIっぽさ」の反復パターンの筆頭にこの型を挙げていますが、本文では「〜ではありません。〜でした」構文が十数回使われています。コントラスト自体が主張になっている箇所（テストできるのは既知の壊れ方だけ、という段落など）だけ残し、他は肯定形で一度だけ言う。例えば第1節末尾は「大切だったのは、生成された候補の何を残し、どの判断を次に持ち越すかの設計だった」と否定パートごと削れます。文の長さが実質半分になります。
方向助詞「へ」の一律使用。 「スクリプトへ移す」「質へ転化する」など、通常「に」を使う箇所までほぼすべて「へ」で統一されており、数十回続くと翻訳調・様式的に響きます。基本を「に」に戻し、移動を強調したい数箇所だけ「へ」を残すと一気に自然になります。
名詞の羅列文・体言止め。 序盤の「マイクロVM…ワークフロー。」のような名詞だけの一文は、記事自身の言う「数え上げ」チックそのものです。「マイクロVMやスナップショット起動、ゼロスケールを追うほど、サーバーレスが磨いてきた原則に行き当たった」のように文へ畳み込めます。
翻訳調・不自然な語。 「短命な資格」→「有効期限の短い認証情報」（credentialsの直訳に見えます）、「真実の源」→「唯一の情報源」、「全書記憶」→「一冊分の記憶」、「濃く直します」→「重点的に直す」、「過去における予測」→「当時の予測」。「制約を工学する」は意図的な造語なら初出で一言断ると引っかかりが減ります。
主述・論理のねじれ。 第3節に、主語が「AIは」なのに述語が「教えたわけではない」となる文があり、文意上は「AIには教えていなかった」のはず。58.2%圧縮の動機が締切を延ばすためと書かれていますが、ページ数が減ると印刷所の締切が後ろ倒しになるという同人誌特有の事情は、一言補足がないと因果が伝わりません。ほかに「執筆途中から、元から〜」の副詞の衝突、LLM Wiki節での「〜ました／〜ます」の時制揺れ、同一文内の「新しい／あたらしい」の表記揺れ。
見出しと決め台詞の過密。 全見出しがレトリカルな一文で、引用ブロックの警句と合わせると「全部が見得」の状態になっています。本の中では頻出する読み筋を六か所から二か所に減らしたとあるので、同じ文体予算の考え方をこの記事にも適用するのが一番の処方箋です。見出しの半分を情報型（「状態はファイルに置く」「制約は層で管理する」など）に落とすだけで緩急が出ます。

実用的な提案をひとつ。本の工程では反復パターンを章単位で数える検査スクリプトまで作られているので、それをこの記事自体に掛ければ、上記の大半（ではなく型・へ・太字・数え上げ）は機械的に検出できるはずです。ご希望なら、この方針で圧縮した構成案（新しい見出し立てと各節の要旨）も作ります。

総評

その感覚はかなり妥当です。この記事は内容が乏しいというより、一つの発見を何度も別の概念や比喩で説明し直しているため、情報量以上に長く感じられます。

中心的な主張は、次の一文にまとめられます。

AIと長編を書くときは、プロンプトを工夫するだけでなく、章間の整合性、表現の重複、根拠、未決事項などの編集判断を外部に記録し、失敗に応じて更新する必要がある。

記事では、この主張を「執筆契約」「制約スタック」「制約工学」「外部記憶」「アブレーション実験」「CEGIS」など、異なる説明枠で繰り返しています。それぞれに多少の違いはありますが、読者から見ると、新しい知見が追加されるというより、同じ知見が再命名されている印象が強くなります。(めもおきば)

制作記録としては詳細に価値があります。しかし、主張を伝える記事として見ると、制作日記、方法論の提案、技術的な比喩、書籍の紹介が一つの記事に同居しており、焦点がぼやけています。(めもおきば)

1. 同じ内容を簡潔に表現するには

構成を7節から4節に減らす

現在の節立ては、それぞれが新しい議論のように見えますが、実際にはかなり重なっています。次の4節で十分です。

章ごとの文章は書けても、本全体が崩れた
編集判断をファイルに残した
既知の失敗は自動検査し、品質は人が判断した
ルールそのものも見直した

「外部記憶」は2節に含められます。「制約工学」「アブレーション」「CEGIS」は4節の補足、または別記事に移せます。

削るべき箇所

現在の内容	編集方針
既刊2冊、新刊の企画変更、AWSの動向、入稿日の説明	冒頭2～3文に圧縮する
「執筆契約」の分類表	残す。ただし4項目程度にする
「制約スタック」の8分類	前の表と統合する
失敗例を5件並べた表	ページ圧縮の1例だけ残す
Obsidian、289本のノート、会話ログ、Gitとの時刻照合	2文に圧縮するか別記事へ移す
CEGISの紹介	読者に必要な概念ではないため脚注へ移す
ファイル名を並べたコードブロック	実装例として付録へ移す
冒頭・途中・末尾の決め台詞	最後の一つだけ残す

特に、二つの分類表は「材料」「編集ルール」「自動検査」「人間の判断」の4分類にまとめられます。現在は、章間契約や文体予算を説明した直後に、それらを「意味契約」「予算」「検査」などへ再分類しており、読者に二度同じ整理をさせています。(めもおきば)

失敗例についても、194ページから大幅に圧縮したものの必要な説明まで失われた、という一例だけで「制約を満たしても良い文章になるとは限らない」という結論は十分伝わります。出典IDやCIの事例まで並べると、主題が執筆論から開発運用論へ逸れてしまいます。(めもおきば)

タイトルも具体化する

現在のタイトルは長く、「一冊の本」「無意識に守っていた」「執筆契約」「発見した」と情報を重ねています。

例えば、次のほうが主張をつかみやすくなります。

AIと長編を書くとき、プロンプトより重要だったもの
AIとの本づくりで見えた、長編を破綻させない編集ルール
AIに一冊を書かせるには、編集判断の共有が必要だった

2. 文体のどこが読みにくいのか

最大の問題は「強い表現」の密度です

記事自身が、AIによって対句、三項構成、決め台詞、問いかけ、比喩が増えたと分析し、「AではなくB」型などを検査対象にしたと説明しています。ところが、この記事自体にも同じ型が多く残っています。(めもおきば)

たとえば見出しだけでも、次のような対置が続きます。

章は書けるが、一冊にはならない
答えではなく、知識差分を探す
契約ではなく、契約を発見する仕組みを持ち込む

対句は一度なら印象に残ります。しかし何度も続くと、すべての段落が「結論らしい言い方」をし始め、どこが本当の結論なのか分からなくなります。強調が多すぎるため、かえって強弱がなくなっています。

主な問題と直し方

問題	読みにくくなる理由	直し方
比喩を重ねすぎる	状態、インターフェース、契約、予算、スタック、工学、アブレーション、考古学と、理解の枠組みが次々に変わる	「編集ルール」という一つの比喩に絞る
内部用語をそのまま出す	「確定正本」「被参照台帳」「文体チック」「思い返し装置」は、意味を覚える負担が大きい	「重要表現の一覧」「章間参照の一覧」「頻出表現」など機能を直接書く
抽象名詞が多い	「候補空間」「意味契約」「知識差分」「作用を絞る」など、具体的な作業が見えにくい	誰が何をしたか、動詞で書く
一文に列挙しすぎる	5～7項目を並べる文が多く、重要度を判断できない	一文の列挙は3項目程度にし、必要なら分類する
比喩と事実の境界が曖昧	「本にも章間インターフェースがあった」と断定すると、比喩なのか方法論なのか分かりにくい	「章間の受け渡しを、インターフェースのように明示した」と書く
文体のレベルが揺れる	few-shot、CI、CEGISなどの専門語と、「使いまくる」「ちょっとした考古学」のような口語が混在する	技術報告調か随筆調のどちらかへ寄せる
結論を何度も言い直す	各節の最後に標語的なまとめがあり、前進感が薄い	結論は冒頭で一度示し、最後に一度だけ回収する

記事の中盤以降では、ソフトウェア開発の概念が、説明のための比喩ではなく議論そのものになっています。「事前分布」「表現空間」「ハードな制約」「アブレーション」「CEGIS」を理解しなくても、本来の知見は説明できます。(めもおきば)

3. 文単位で不自然なところ

時制が揺れている

章ごとにAIへ書かせた過去の経験を説明しているのに、途中で現在形になります。

「書いてもらうと、それぞれの出力は単独ではよくできています」
修正案：「書いてもらったところ、それぞれの出力は単独ではよくできていました」

同じ段落の中で、過去の出来事と一般論を切り替えるなら、切り替えを明確にしたほうが読みやすくなります。(めもおきば)

助詞や語の選び方が不自然

細部には、次のような引っかかりがあります。

「一文は入れ忘れ」 → 「一文を入れ忘れ」
「書き直しはじめました」 → 「書き直しを始めました」
「文章の品質を数値へ置き換えた」 → 「文章の品質を数値に置き換えた」
「制約自身を壊し」 → 「制約そのものを見直し」
「削減を復元しました」 → 「削った箇所を戻しました」

「削減を復元する」は、行為を戻すのか、削られた文章を戻すのかが曖昧です。具体的な対象を主語・目的語に置くと自然になります。(めもおきば)

語の係り先が曖昧

「AIっぽい違和感」を複数のパターンに分け、それを「章単位の上限とスクリプトへ落とした」という説明があります。しかし、違和感そのものを上限へ変換したように読めます。

次のようにすると明確です。

AIらしく見える反復をいくつかのパターンに分解した。それぞれに出現回数の上限を設け、スクリプトで検出できるようにした。

同様に、

自然さ、技術的な射程、安全性、反例、責任の引受先は、人間のレビューへ残ります。

という文も、性質の異なる項目が並び、「反例がレビューへ残る」という係り方になっています。

文章の自然さ、技術的な妥当性、安全性などは、人がレビューする。

程度で十分です。(めもおきば)

因果関係が省略されている

「入稿締切を延ばすためにページ数を減らした」という箇所は、印刷所の料金・締切体系を知らない読者には因果が分かりません。

意図が「ページ数を減らせば、より遅い入稿期限を選べた」ということなら、そう明記すべきです。

ページ数を減らせば入稿期限を後ろ倒しできたため、194ページの原稿を113ページまで圧縮した。

専門的な前提を省略したまま数字だけ詳しく書くと、具体的なのに状況が理解できない文になります。(めもおきば)

4. 同じ主張を短く書き直した例

AIと長編を書くとき、プロンプトより重要だったもの

ClaudeやChatGPTと技術書を改稿した。章ごとの草稿はそれぞれ読めるものの、一冊にまとめると表現が重複し、章間の参照や予定していた説明が抜けた。AIの会話セッションは、本全体についての編集判断を共有していないからだ。

そこで、目次、ページ配分、章間の依存関係、未検証の主張、重要な言い回しをファイルにまとめた。各セッションの開始時にそのファイルを読ませ、作業後に新しい判断を書き戻すようにした。

さらに、各章が何を引き継ぎ、何を説明し、何を次章へ渡すかを決めた。同じ比喩や決め台詞を何度使うか、変わりやすい情報を本文とデジタル付録のどちらに置くか、主張をどの資料で裏づけるかも一覧化した。私は、こうした編集ルールを「執筆契約」と呼んだ。

重複表現、ページ数、参照漏れなど、機械で判断しやすい問題はスクリプトで検査した。一方、文章の自然さ、技術的な妥当性、安全性は人が判断した。自動検査の役割は、良い文章を保証することではなく、すでに分かっている失敗を繰り返さないことにある。

ただし、ルールは多ければよいわけではない。ルールを守った結果、必要な説明や文章のリズムが失われることもあった。その場合は、ルールを外した案と比較し、原稿ではなくルールのほうを見直した。

過去のノートも、AIに答えを作らせるためではなく、原稿に足りない材料を探すために使った。必要な情報は、改めて一次資料で確認した。

今回の経験から、次の本へ持ち越すべきなのは個々のルールではなく、失敗を記録し、検査可能なものを仕組みに変え、不要になったルールを捨てる手順だと分かった。AIによって文章を作る費用が下がるほど、何を採用し、なぜ直したかを残す編集工程が重要になる。

この形なら、記事の主要な要素である全体状態の管理、執筆ルール、自動検査と人間レビューの分担、ルールの更新、外部ノートの利用を残しつつ、大幅に短くできます。

要するに、削るべきなのは情報そのものよりも、再命名、比喩の追加、分類のやり直し、結論の言い直しです。この記事が提案している「文体予算」を、この記事自身にもう一段厳しく適用すると、かなり読みやすくなります。

nekoruri/1_prompt.md

Select an option

No results found