https://ttf248.life/ja/tags/blog-style-suite/ Recent content in Blog-Style-Suite on 向叔の手帳 Hugo -- gohugo.io ja Thu, 09 Apr 2026 15:45:31 +0800 https://ttf248.life/ja/p/how-i-split-local-online-and-minimax-models/ Fri, 03 Apr 2026 21:06:02 +0800 https://ttf248.life/ja/p/how-i-split-local-online-and-minimax-models/ <p>倉庫の構成を一周確認した結果、逆に確信したことがあります。このシステムは、単体のモデルがどれだけ強力かではなく、どのレイヤーにコストを負わせるべきか、という点にかかっているということです。</p> <p>最も明白なシグナルは、現在有効な <code>published.runtime.json</code> が依然として 2026年4月2日に生成された <code>minimax-m2</code> であることです。しかし、2026年4月3日16:38の <code>5f17088</code> は、<code>blog-style-suite</code> のデフォルトプロバイダーをローカルの <code>LM Studio</code> 内の <code>gemma-4-26b-a4b</code> に切り替えています。これは一見すると前後で矛盾しているように見えますが、実はそうではありません。むしろ、このパイプラインに分業が始まったことを示しています。</p> <p>この記事群はここまでで、最初の2本で境界線を描きました。<a class="link" href="https://ttf248.life/ja/p/why-blog-writer-had-to-exist/" >第1回</a> では、<code>blog-writer</code> がなぜ生まれたのかを語り、<a class="link" href="https://ttf248.life/ja/p/how-blog-style-suite-split-style-and-token-cost/" >第2回</a> では、<code>blog-style-suite</code> がどのようにスタイル学習とトークンコストを分離したのかを語りました。そして最後のこの記事では、最も現実的な問題に焦点を当てます。ローカルモデル、オンラインモデル、<code>Minimax</code> は、結局どのワークステーションに置くべきなのか、という点です。</p> <h2 id="スタイルデータでのトレーニングはすべてのステップでオンラインモデルを焼く価値はない">スタイルデータでのトレーニングは、すべてのステップでオンラインモデルを焼く価値はない </h2><p>スタイルデータというものは、真剣に取り組むと、トークンがすぐに現実的な問題になります。 やりたいかどうかではなく、役割分担をしないと、このシステム全体が長く動きません。 以前最も陥りがちだった誤解は、一つのオンラインモデルにすべての作業を任せてしまうことでした。</p> <ul> <li>過去記事のクロール</li> <li>スクリーニングの実施</li> <li>分類を行う</li> <li>スコアリング</li> <li>サンプルの抽出</li> <li>スタイルの調整（トーン合わせ）</li> <li>そして最後に原稿を書く このように行う最大の問題は、「モデルが十分強力でない」ことではなく、すべてのステップで同じコストを消費してしまうことです。 今振り返ると、真に合理的なアプローチは逆から考えるべきです。どのステップはオンラインで行う必要があるのか、どのステップは可能な限りローカル化すべきなのか、さらにはモデルに任せるべきではないステップがあるのか、という点です。 この境界線が不明確なままだと、どれだけ強力なモデルを導入しても、結局は本来前処理で対応できたはずの作業を繰り返すだけになってしまいます。</li> </ul> <h2 id="ローカルモデルは汚い作業重労働そして試行錯誤の繰り返しに適している">ローカルモデルは「汚い作業」「重労働」、そして「試行錯誤の繰り返し」に適している </h2><p>私は今や、ローカルモデルを本番環境における「体力層（ワークホース）」として定義するようになりつつあります。 必ずしも最強である必要はなく、毎回最も洗練されているわけでもありませんが、以下のタスクを担うのに特に適しています：</p> <ul> <li>何度も実行する構築プロセス</li> <li>スタイルデータの複数ラウンドにわたる圧縮実験</li> <li>設定変更後の再スキャン</li> <li>既存の構造に対する低リスクな再計算 これらの作業には共通点があります。 それは単発で価値が極めて高いことではなく、<strong>繰り返し実行する必要がある</strong>、<strong>試行錯誤を許容できる</strong>、そしてできれば<strong>毎回高額なコストを払う必要がない</strong>という点です。 現在、<code>scripts/blog-style-suite/config.json</code> は <code>lm-studio-gemma4</code> に切り替わっており、これ自体が判断が変わっていることを示しています。ローカルの <code>gemma</code> がオンラインモデルより必ずしも強いわけではなく、むしろ本番環境のこのパイプラインは、「実行可能か」「頻繁に実行できるか」「繰り返し変更できるか」を優先し始めたのです。 これは、私が以前書いた <a class="link" href="https://ttf248.life/ja/p/weaker-models-shouldnt-do-frontier-work/" >弱モデルに無理に高度なタスクを割り当てない</a> と同じ論理に基づいています。 ローカルモデルが複雑な記事全体をゼロから書き上げるのに適しているとは限りませんが、**「汚い作業」「重労働」「バッチ処理」**を受け持つには非常に適しています。スタイルデータの前処理は、元々このようなタスクに近いです。</li> </ul> <h2 id="オンラインモデルは仕上げに向いており全てをこなすのには向かない">オンラインモデルは「仕上げ」に向いており、「全てをこなす」のには向かない </h2><p>ローカルモデルがプロダクション側に向いているからといって、オンラインモデルに価値がないわけではありません。 オンラインモデルが真価を発揮するのは、まさに最後の「仕上げ（クロージング）」の部分です。 例えば：</p> <ul> <li>最新の情報に基づいて事実を補完する</li> <li>より大きなコンテキストの中で論証を整理する</li> <li>ネットワーク接続による検証が必要な時間的制約のある情報を処理する</li> <li>すでに準備された構造化されたスタイルアセットを、公開できる記事に仕上げる これらの動作は、表現の質、事実の統合、コンテキスト理解といった要求が高いため、オンラインモデルがここに配置される方が価値が高いのです。 つまり、強力なモデルはまるで総組立ラインの最後の工程のようなものです。前工程まで手を広げられるわけではありませんが、最初から最後まで全てを処理させると、コスト構造がすぐに崩れてしまいます。 これが、<code>blog-writer</code> が設計上、投稿済みデータである <code>published.runtime.json</code> のみを読み取り、原稿作成時にプロバイダーを切り替えたり、スイートディレクトリ全体を再走査したりしない理由です。消費側（クライアント側）が軽いほど、より強力なモデルに記事の「仕上げ」に集中してもらうのが最適なのです。</li> </ul> <h2 id="minimax-の意味は単にプロバイダーを増やしただけではない">Minimax の意味は、単にプロバイダーを増やしただけではない </h2><p>多くの人は「Minimax」を見ると、「またモデルを一つ追加しただけか」と最初に思いがちです。</p> <p>しかし、そうは思いません。</p> <p><code>Minimax</code> が真に価値があるのは、「複数のプロバイダーからの出力を、単一の公開契約（スキーマ）で消費できる道筋を作った」点にあります。</p> <p>2026年4月2日 10:18 の <code>9f15199</code> で <code>blog-style-suite</code> がマルチモデル構成に変更され、出力がプロバイダーごとに分離されました。その後も README やランタイムの構造では、常に一つのことを強調しています。それは、スイートは多くの結果を生成できるが、実際に有効なのは人間が選んだ <code>published.runtime.json</code> だけだということです。</p> <p>この境界線（バウンダリー）が非常に重要です。</p> <p>なぜなら、一度この境界が明確になると、<code>Minimax</code> の役割は「執筆プロセスに組み込まれなければならないもの」から、以下のようなものへと変わるからです。</p> <ul> <li>本番環境での比較に参加できる</li> <li>ランタイム版を生成するために使える</li> <li>ローカルモデルの成果物と横断的に比較できる</li> <li>最終的に人間がどのバージョンを公開するかを決定する</li> </ul> <p>これにより、プロバイダーは「システムへの依存」から「交換可能な部品」へと変わりました。</p> <p>これが、このエンジニアリングスタックにおける <code>Minimax</code> の最も興味深い意義だと私は感じています。それは、エンドツーエンドの全工程を支配するために存在するのではなく、「このリンク（プロセス）がインターフェースをきれいに受け止めているかどうかを検証する」ために存在しているのです。</p> <h2 id="真の役割分担はモデルの強さによるのではなくタスクの種類によるべき">真の役割分担は、モデルの強さによるのではなく、タスクの種類によるべき </h2><p>私は今、非常に古風だが実用的な分類法をより支持しています。</p> <h3 id="ルールとハード制約">ルールとハード制約 </h3><p>ローカルスクリプトに任せる。 <code>scanner.py</code>、<code>write_post.py</code>、<code>write_post_series.py</code> のような決定論的なツールで解決できることは、モデルに混ぜ込ませないこと。</p> <h3 id="スタイルデータ生成">スタイルデータ生成 </h3><p>ローカルモデルまたはコストの低いプロバイダーを優先します。 ここでの最も重要なのは、単発の出力が最も華やかであることではなく、再現性、試行錯誤可能性、キャッシュ可能性です。</p> <h3 id="最終原稿作成と事実の締めくくり">最終原稿作成と事実の締めくくり </h3><p>より長いコンテキストの統合、表現の収束、およびインターネットからの事実補完に適したモデルに任せる。 このレイヤーこそが、オンラインモデルにお金をかける価値がある場所だ。 このように分解すると、以前は悩んでいた問題も実はそれほど複雑ではないことがわかる。毎日「どのモデルが最強なのか」を議論する必要はなく、「このタスクはどのレイヤーに属するか」と尋ねるだけでよいのだ。</p> <h2 id="結局最も価値があるのはモデルではなく境界が明確なことである">結局、最も価値があるのはモデルではなく境界が明確なことである </h2><p>第3編はここまでとさせていただきます。 <code>blog-writer</code> と <code>blog-style-suite</code> という一連のものは、進化する過程で、誰を接続したか、誰に入れ替えたか、どのプロバイダーを試したかといった点よりも、最も価値があるのは境界が徐々に明確になってきたことです。</p> <ul> <li><code>blog-writer</code> は消費側を担当</li> <li><code>blog-style-suite</code> は生成側を担当</li> <li><code>published.runtime.json</code> が公開の場所である</li> <li>ローカルモデルは繰り返し実行する面倒な作業や重い作業に適している</li> <li>オンラインモデルは最後の仕上げに適している</li> <li><code>Minimax</code> のようなオンラインプロバイダーは、システムの中枢というよりも交換可能な部品のようなものだ。 境界が明確になると、ワークフロー全体がスムーズになる。 一つのモデルパッケージだけで全てを解決できると期待したり、全てのステップを最も高価なレイヤーに積み重ねたりすることはなくなる。結局のところ、これはモデルを選ぶように見えて、実際には異なる種類のタスクに作業場所を割り当てているだけなのだ。 端的に言えば、単一の点が強いのはもちろん良いことだ。 しかし、長期的に見ると、境界が明確であることは、単一の点よりも強く、より重要であることが多い。</li> </ul> <h2 id="参考資料">参考資料 </h2><ul> <li>リポジトリコミット：<a class="link" href="https://github.com/ttf248/notebook/commit/9f1519967981c5eef7bd1eb407b0406ac542ebd0" target="_blank" rel="noopener" ><code>9f1519967981c5eef7bd1eb407b0406ac542ebd0</code></a></li> <li>リポジトリコミット：<a class="link" href="https://github.com/ttf248/notebook/commit/5f17088391ee858b88fc50df884bc0103ff0b3c1" target="_blank" rel="noopener" ><code>5f17088391ee858b88fc50df884bc0103ff0b3c1</code></a></li> <li>リポジトリファイル：<code>scripts/blog-style-suite/config.json</code></li> <li>有効なランタイム：<code>.agents/data/blog-writing/published.runtime.json</code></li> <li>関連旧記事：<a class="link" href="https://ttf248.life/ja/p/a-long-period-of-deep-ai-programming/" >重度AIプログラミングの日々</a></li> <li>関連旧記事：<a class="link" href="https://ttf248.life/ja/p/ultimately-its-returning-to-domestic-models/" >結局は国産モデルに戻る</a></li> <li>関連旧記事：<a class="link" href="https://ttf248.life/ja/p/weaker-models-shouldnt-do-frontier-work/" >弱モデルに無理な強活を適用しない</a></li> </ul> <h2 id="作成上の注記">作成上の注記 </h2><h3 id="元のプロンプト">元のプロンプト </h3><pre><code class="language-text">$blog-writer 今回の内容は多いため、シリーズ記事に分割しました。昨年も多くの原稿が大規模言語モデルによって書かれました。その時は、自分でアウトラインや質問リストを作成し、AIに原稿を生成させ、内容をローカルのmdドキュメントにコピーし、ヘッダー情報、タグ情報などを記入して投稿するという流れでした。最近はCodexを多く使用し、Codexのインターネット検索能力が非常に強力だと気づきました。そこで、これらの作業を自動化するスキルを作成できないかと考えたのが、skill blog-writerの初稿です。さらに、AIに以前の記事のスタイルを学習させたいと考えたため、blog-writerの実行時にトークンを大量に消費するという問題が発生しました。その後、私はblog-writerに対して複数のバージョンの最適化を行いました。データモジュールとデータ生成モジュールに分割したのですが、元々のデータ生成モジュールは独立したスキルとして存在していました。書き進めるうちに、Pythonプロジェクトとしてまとめた方がより適していることに気づき、それがblog-style-suiteの誕生につながりました。さらに、スタイルデータの学習もトークンを消費することが多いため、ローカルの大規模言語モデルを使用することにしました。ローカルの大規模言語モデルとオンライン版の違いを比較したいと考えたため、minimaxとも連携させました。blog-style-suiteとblog-writerの進化の歴史は、gitのコミット履歴から分析できます。ついでに、ローカルのblog-writerやblog-style-suiteのコードを基にして、設計思想（どのようにトークン節約を実現したか、データ構造をどう設計したか、核となる設計思想）について説明することも可能です。トークンが潤沢であれば過去の記事を丸ごと処理できますし、前処理を行うことで多くのトークンを節約できます。 </code></pre> <h3 id="ライティングの骨子まとめ">ライティングの骨子まとめ </h3><ul> <li>第3編では、アーキテクチャの説明を繰り返すのではなく、「モデルの役割分担」という現実的な問題に焦点を当てて締めくくる。</li> <li>冒頭で、現在のリポジトリにある <code>published.runtime.json</code> が <code>minimax-m2</code> や <code>config.json</code> からローカルの <code>gemma4</code> に切り替わっているという事実を直接提示し、前置きを減らす。</li> <li>重要なのは、誰がより優れているかを証明することではなく、なぜ異なるタスクを異なるコストレイヤーに割り当てるべきなのかを説明することである。</li> <li><code>Minimax</code> を「交換可能なプロバイダー」の位置で語るのは、その意義をモデルのベンチマークリストではなく、エンジニアリングの境界線に引き戻すためである。</li> <li>最後に、「単一の最高性能よりも明確な境界線の方が重要である」という全体的な判断に戻り、一連の記事を締めくくる。</li> </ul> https://ttf248.life/ja/p/how-blog-style-suite-split-style-and-token-cost/ Fri, 03 Apr 2026 21:02:02 +0800 https://ttf248.life/ja/p/how-blog-style-suite-split-style-and-token-cost/ <p>トークンが十分にある場合、最も手っ取り早い方法は非常に粗暴ですが、過去の記事をそのままモデルに投入し、自分で学ばせることです。</p> <p>問題は、この方法はたまに1記事書くのには適していますが、繰り返し書くのには適さないということです。もしブログ執筆を長期的なワークフローとして真剣に取り組むのであれば、「生データ（歴史的な文章）」というアプローチは、すぐに「高コストで散漫」になってしまいます。</p> <p>この一連の記事では、主軸が移りました。前回の記事 <a class="link" href="https://ttf248.life/ja/p/why-blog-writer-had-to-exist/" >AIによるブログ執筆は、結局エンジニアリングにする必要がある（1）：blog-writerがなぜ生まれてきたか</a> では、消費側（コンテンツの利用側）の自動化について取り上げました。この記事からは生産側、つまりスタイルデータがどのように生成され、どのように圧縮され、どうすればトークンを無駄に燃焼させないかという点について語ります。次の記事では <a class="link" href="https://ttf248.life/ja/p/how-i-split-local-online-and-minimax-models/" >AIによるブログ執筆は、結局エンジニアリングにする必要がある（3）：ローカルモデル、オンラインモデル、そしてMinimaxの役割分担</a> を続けます。</p> <h2 id="最初の一番自然な発想は過去の記事をそのまま与えることだ">最初の一番自然な発想は、過去の記事をそのまま与えることだ </h2><p>この道筋は本当に自然すぎる。 モデルにあなたの書き方を学ばせたいのなら、最も直感的な方法はもちろん、古い記事を餌として与えることだ。できれば、過去のブログの中で自分自身に一番近いと感じるものを詰め込んで、自分で要約させるのがベストだ。 一度きりのタスクを見る限りでは、これを行っても問題はない。 むしろ多くのケースで効果は良い。コンテキストが十分長く、モデルが十分に強力で、過去の記事が十分にあれば、スタイルを習得することは確かに可能だ。 しかし、問題は「この記事を書き上げられるか」ではなく、「次の記事、その次の記事も、これを繰り返さなければならないのか」ということなのだ。 毎回古い記事のバッチを再投入することは、いくつかの非常に現実的な副作用をもたらす：</p> <ul> <li>同じ材料が繰り返しコンテキストを占有する</li> <li>トークン消費量が執筆回数にほぼ線形に増加する</li> <li>モデルが見るノイズが増えすぎ、真に有用なシグナルが逆に希釈されてしまう</li> <li>執筆という動作とスタイル維持という動作が完全に結びつき、どちらも軽々しくできなくなる つまり、トークンが潤沢な時は、生で与えるのはもちろん可能だ。しかし、工学的な観点から常にこのようにすることはできないのだ。</li> </ul> <h2 id="これがデータモジュールとデータ生成モジュールを分離しなければならない理由です">これがデータモジュールとデータ生成モジュールを分離しなければならない理由です </h2><p>後になって考えたところ、核心は一言に尽きます。「消費側」と「生産側」を分けることです。</p> <p><code>blog-writer</code> が担当しているのは消費側です。これは、すでに公開されたランタイムを読み取り、固定の契約に従って記事を書き出すだけです。</p> <p>一方、スタイルデータのスキャン、フィルタリング、スコアリング、圧縮、プロバイダー比較などは、別の生産側のパイプラインに置かれるべきでした。つまり、後から作られた <code>blog-style-suite</code> のようなものです。</p> <p>gitの履歴を見れば、この転換は非常に明確です。</p> <p>2026年4月1日 21:47 のコミット <code>84a06b5</code> で、元の <code>blog-style-maintainer</code> スキルがリポジトリレベルのCLIツールに置き換えられたことが明記されています。この動きは物事を物語っています。なぜなら、<code>scan/build/rebuild</code> があり、出力ディレクトリがあり、リカバリ機構がある時点で、それはもはや単なる「スキル」ではなく、通常のPythonプロジェクトのように見えてくるからです。</p> <p>さらに2026年4月1日 23:05 のコミット <code>9e92b8e</code> では、<code>blog-style-suite</code> が <code>scanner.py</code>、<code>builder.py</code>、<code>compressor.py</code> といったモジュールに分割され続けました。この段階に至ると、考え方はすでに非常に工学的なものになっています。</p> <ul> <li><code>scanner.py</code>: ディスクから記事をスキャンし、構造化された特徴を抽出する役割</li> <li><code>builder.py</code>: スコアリング、選別、キャッシュ、ランタイムアセンブリの役割</li> <li><code>compressor.py</code>: モデルが関与するいくつかの圧縮ステップを担当する</li> </ul> <p>これは、単にスーパープロンプトを一段書くというアプローチとは、全く異なる考え方なのです。</p> <h2 id="トークンを節約するのは玄学ではなく前処理とバッチ化によるもの">トークンを節約するのは、玄学ではなく前処理とバッチ化によるもの </h2><p>このエンジニアリングセットで真に価値があるのは、2026年4月2日19:41の<code>bc4b950</code>だと思います。</p> <p>あのコミットは非常に率直なことを述べていました。AIの呼び出し回数が約「2000回」から、各プロバイダーで最大「5回」に直接削減されたのです。</p> <p>どうやって達成したのか？ それは「プロンプトをより賢くする」のではなく、<strong>事前に処理すべきものを前もって実行する</strong>ことによるものです。</p> <p>現在の<code>blog-style-suite</code>のフローは非常に明確になりました：</p> <ol> <li><code>scan</code>フェーズは純粋にヒューリスティックであり、AI呼び出しは0回。</li> <li><code>build</code>フェーズではまずヒューリスティックなスコアリングを行い、これもAI呼び出しは0回です。</li> <li>その後、<code>technical / finance / essay / tooling</code>の4つのレーンそれぞれで1回のバッチ選別とラベリングを行います。</li> <li>最後に作者スタイルの圧縮を1回行います。</li> </ol> <p>これを計算すると、コールドスタートでも最大5回の呼び出しに抑えられます。</p> <p>さらに重要なのは、この5回が各記事に分散しているのではなく、<strong>すでに前処理された高価値な要約材料に集中している</strong>点です。</p> <p>これが前処理が真にトークンを節約する部分です。単に数文字を減らすのではなく、「記事ごとに呼び出す」から「フェーズごとに集中的に呼び出す」というパラダイムシフトなのです。</p> <p>その後は、キャッシュも整備されました。 <code>builder.py</code>にはレーンのバッチフィンガープリントがあり、プロバイダーのチェックポイント復元機能があり、さらにローカルモデルのコンテキストのために<code>review_pool_per_lane = 12</code>のような縮小化が行われています。少しデータを変更しただけで、パイプライン全体を再実行する必要がありません。</p> <p>こうした設計は一見派手ではありませんが、一つ一つが非常に実用的です。なぜなら、それらはすべて「同じトークン群を二度と無駄に燃焼させない」という問題を解決しているからです。</p> <h2 id="現在のデータ構造は本質的に真に有用なシグナルを圧縮しているものだ">現在のデータ構造は、本質的に真に有用なシグナルを圧縮しているものだ </h2><p>この構造を分解すれば、データ構造も整理されるだろう。 私は今、これを3層として理解する方がより良いと感じている。</p> <h3 id="第1層scanjson">第1層：<code>scan.json</code> </h3><p>これは共有の原料です。 ここには、記事のパス、タイトル、日付、カテゴリ、タグ、冒頭段落、クロージングスタブ、見出し、スクリーニング結果、レーン分類といった構造化されたシグナルが格納されています。 これは <code>blog-writer</code> に直接渡されるものではなく、生産側でさらに加工するためのものです。</p> <h3 id="第2層providersourcejson">第2層：<code>{provider}.source.json</code> </h3><p>これはプロバイダーレベルのチェックポイントです。 共有された原料に加え、スコアリング結果、レーン選択、フィンガープリント、キャッシュステータスといった中間状態が追加されています。つまり、「加工過程の中間製品」のようなものであり、復元可能、再利用可能、中断して再開できる点が重要です。</p> <h3 id="第3層providerruntimejson-と-publishedruntimejson">第3層：<code>{provider}.runtime.json</code> と <code>published.runtime.json</code> </h3><p>これが消費側が真に気にする完成品です。 ここには以下のものが保持されています：</p> <ul> <li><code>author_style</code></li> <li><code>lanes</code></li> <li><code>samples</code></li> <li><code>writer_guide</code> つまり、元々大量にあった過去の記事群を、そのまま利用できるランタイムスタイルアセットとして圧縮したものになります。 特に <code>published.runtime.json</code> という公開用のファイルが重要です。<code>blog-writer</code> はこのファイルのみを読み取り、<code>content/post</code> を再スキャンしたり、suite ディレクトリ内の全プロバイダーの完全なイメージを気にする必要がなくなります。 この境界線が引かれることで、消費側は軽量化します。執筆モデルが見るのは、もはや原始的な古い記事の山ではなく、すでに前処理された高密度のシグナルとなるのです。</li> </ul> <h2 id="すべてのことをモデルにさせるべきではない">すべてのことをモデルにさせるべきではない </h2><p>最近、このエンジニアリングにおいて最も正しい判断は、「モデルを多く追加すること」ではなく、「モデルに任せるべきでないこともモデルに投げ渡さないこと」だと感じています。</p> <p>以下のようなことは、ローカルルールで処理する方が適しています：</p> <ul> <li>frontmatter の解析</li> <li>冒頭段落の抽出</li> <li>見出し（headings）の抽出</li> <li>本人/転載/モデルによる署名の判断</li> <li>blockquote の比率チェック</li> <li><code>&lt;!--more--&gt;</code> や埋め込みプロンプト、本文の長さといったハードルルールでのフィルタリング</li> </ul> <p>これらの作業をモデルにやらせることは不可能というわけではなく、単に無駄です。</p> <p>モデルがより適しているのは、曖昧さやトレードオフを含む部分です。例えば、「あるレーンの中でどの記事が現在の論調をよりよく代表しているか」、あるいは「高評価の記事から著者のスタイルタグを抽出する」といった作業です。</p> <p>そのため、<code>blog-style-suite</code> が真に価値があるのは、「トークンを節約できる」という点だけではなく、人間、ルール、モデルのそれぞれが担当すべき役割を再定義した点にあるのです。</p> <h2 id="前処理はトークンを節約するためではなく執筆作業を持続可能にするためである">前処理はトークンを節約するためではなく、執筆作業を持続可能にするためである </h2><p>第2回の結論について、もっと直接的に伝えたい。 トークンが潤沢な時は、過去の記事をそのまま使うのはもちろん問題ない。むしろ、本当に1〜2本だけ書くなら、頭を使う量が少ないかもしれない。 しかし、このことを長期的なワークフローにしたいと思うなら、前処理は選択肢ではなくなる。なぜなら、前処理をしないと、執筆モデルは毎回古い素材を見直さなければならず、スタイルの維持と記事生成が常に混ざり合ってしまうからだ。 <code>blog-style-suite</code> の意味するところは、このごちゃ混ぜになっているものを分解することにある。 システムに見せるためでも、プロジェクト名を増やすためでもなく、<code>blog-writer</code> が軽快に、安定して、「執筆」という一つの動作だけに集中できるようにするためなのだ。 ここまで来ると、次のステップの問題は自然とついてくる。 すでに生成側が独立した以上、このコストをどのモデルに負わせるべきなのか？ローカルモデル、オンラインモデル、<code>Minimax</code> はそれぞれどの工程に立つべきなのか？この件については、次回の記事 <a class="link" href="https://ttf248.life/ja/p/how-i-split-local-online-and-minimax-models/" >AIでブログを書くという行為は、結局エンジニアリングにする必要がある（三）：ローカルモデル、オンラインモデル、そして Minimax の役割分担</a> で触れることにする。</p> <h2 id="参考資料">参考資料 </h2><ul> <li>リポジトリコミット：<a class="link" href="https://github.com/ttf248/notebook/commit/84a06b5dc743f2e9bc6e788d53496a1261bc63ae" target="_blank" rel="noopener" ><code>84a06b5dc743f2e9bc6e788d53496a1261bc63ae</code></a></li> <li>リポジトリコミット：<a class="link" href="https://github.com/ttf248/notebook/commit/9e92b8e6a15d03e6392aff7f3b2dcb0992fe5043" target="_blank" rel="noopener" ><code>9e92b8e6a15d03e6392aff7f3b2dcb0992fe5043</code></a></li> <li>リポジトリコミット：<a class="link" href="https://github.com/ttf248/notebook/commit/bc4b950cbb13e37d1fdb16a9d23325cfefa6f90e" target="_blank" rel="noopener" ><code>bc4b950cbb13e37d1fdb16a9d23325cfefa6f90e</code></a></li> <li>リポジトリファイル：<code>scripts/blog-style-suite/README.md</code></li> <li>リポジトリファイル：<code>scripts/blog-style-suite/style_pipeline/scanner.py</code></li> <li>リポジトリファイル：<code>scripts/blog-style-suite/style_pipeline/builder.py</code></li> <li>リポジトリファイル：<code>scripts/blog-style-suite/style_pipeline/compressor.py</code></li> <li>有効なランタイム：<code>.agents/data/blog-writing/published.runtime.json</code></li> </ul> <h2 id="作成上の注記">作成上の注記 </h2><h3 id="元のプロンプト">元のプロンプト </h3><pre><code class="language-text">$blog-writer 今回の内容は多いため、シリーズ記事に分割しました。昨年も多くの原稿が大規模言語モデルによって書かれました。その際は、自分でアウトラインや質問リストを作成し、AIに原稿を生成させ、内容をローカルのmdドキュメントにコピーし、ヘッダー情報、タグ情報などを記入して投稿するという流れでした。最近はCodexを多く使用し、Codexのインターネット検索能力が非常に強力だと気づいたため、これらの作業を自動化するskillを作成できないかと考えました。これがskill blog-writerの初稿の誕生につながりました。また、AIに以前の記事のスタイルを学習させたいと考えたため、blog-writerの実行時にトークンを大量に消費するという問題が発生しました。その後、私はblog-writerに対して複数のバージョンの最適化を行いました。データモジュールとデータ生成モジュールに分割したのですが、元々のデータ生成モジュールは独立したskillでした。書き進めるうちに、Pythonプロジェクトとしてまとめた方がより適していることに気づき、それがblog-style-suiteの誕生につながりました。さらに、スタイルデータの学習もトークンを消費することが多いと感じたため、ローカルの大規模言語モデルを使用することにしました。ローカルの大規模言語モデルとオンライン版の違いを比較したいと考え、minimaxを組み込みました。blog-style-suiteとblog-writerの進化の歴史は、gitのコミット履歴から分析できます。ついでに、ローカルのblog-writerやblog-style-suiteのコードを基にして、設計思想（どのようにトークン節約を実現したか、データ構造をどう設計したか、核となる設計思想）について説明することができます。トークンが潤沢であれば過去の記事を丸ごと処理できますし、前処理を行うことで多くのトークンを節約できます。 </code></pre> <h3 id="ライティングの骨子要約">ライティングの骨子（要約） </h3><ul> <li>本稿では、執筆という行為からデータエンジニアリングへと焦点を移し、「なぜモジュール化する必要があるのか」という核心的な問いに答えることを目指した。</li> <li>冒頭で「生きた歴史の記事をそのまま使える」と認めることで、後続の分割理由に説得力を持たせている。</li> <li><code>scan.json</code>、<code>source.json</code>、<code>runtime.json</code> の三層構造を重点的に展開し、単なるアーキテクチャの説明に留まらないようにした。</li> <li><code>bc4b950</code> を中間地点の転換点として配置した。なぜなら、「約2000回から5回へ」という変化が前処理の価値を最も明確に示すためである。</li> <li>最後に、消費側と生産側を再分離し、次回の記事で扱うモデルの役割分担への布石を打った。</li> </ul>