ワークフロー on 向叔の手帳

AIがブログを書くという件は、結局エンジニアリングにする必要がある（2）

Fri, 03 Apr 2026 21:02:02 +0800

トークンが十分にある場合、最も手っ取り早い方法は非常に粗暴ですが、過去の記事をそのままモデルに投入し、自分で学ばせることです。

問題は、この方法はたまに1記事書くのには適していますが、繰り返し書くのには適さないということです。もしブログ執筆を長期的なワークフローとして真剣に取り組むのであれば、「生データ（歴史的な文章）」というアプローチは、すぐに「高コストで散漫」になってしまいます。

この一連の記事では、主軸が移りました。前回の記事 AIによるブログ執筆は、結局エンジニアリングにする必要がある（1）：blog-writerがなぜ生まれてきたかでは、消費側（コンテンツの利用側）の自動化について取り上げました。この記事からは生産側、つまりスタイルデータがどのように生成され、どのように圧縮され、どうすればトークンを無駄に燃焼させないかという点について語ります。次の記事では AIによるブログ執筆は、結局エンジニアリングにする必要がある（3）：ローカルモデル、オンラインモデル、そしてMinimaxの役割分担を続けます。

最初の一番自然な発想は、過去の記事をそのまま与えることだ

この道筋は本当に自然すぎる。モデルにあなたの書き方を学ばせたいのなら、最も直感的な方法はもちろん、古い記事を餌として与えることだ。できれば、過去のブログの中で自分自身に一番近いと感じるものを詰め込んで、自分で要約させるのがベストだ。一度きりのタスクを見る限りでは、これを行っても問題はない。むしろ多くのケースで効果は良い。コンテキストが十分長く、モデルが十分に強力で、過去の記事が十分にあれば、スタイルを習得することは確かに可能だ。しかし、問題は「この記事を書き上げられるか」ではなく、「次の記事、その次の記事も、これを繰り返さなければならないのか」ということなのだ。毎回古い記事のバッチを再投入することは、いくつかの非常に現実的な副作用をもたらす：

同じ材料が繰り返しコンテキストを占有する
トークン消費量が執筆回数にほぼ線形に増加する
モデルが見るノイズが増えすぎ、真に有用なシグナルが逆に希釈されてしまう
執筆という動作とスタイル維持という動作が完全に結びつき、どちらも軽々しくできなくなるつまり、トークンが潤沢な時は、生で与えるのはもちろん可能だ。しかし、工学的な観点から常にこのようにすることはできないのだ。

これがデータモジュールとデータ生成モジュールを分離しなければならない理由です

後になって考えたところ、核心は一言に尽きます。「消費側」と「生産側」を分けることです。

blog-writer が担当しているのは消費側です。これは、すでに公開されたランタイムを読み取り、固定の契約に従って記事を書き出すだけです。

一方、スタイルデータのスキャン、フィルタリング、スコアリング、圧縮、プロバイダー比較などは、別の生産側のパイプラインに置かれるべきでした。つまり、後から作られた blog-style-suite のようなものです。

gitの履歴を見れば、この転換は非常に明確です。

2026年4月1日 21:47 のコミット 84a06b5 で、元の blog-style-maintainer スキルがリポジトリレベルのCLIツールに置き換えられたことが明記されています。この動きは物事を物語っています。なぜなら、scan/build/rebuild があり、出力ディレクトリがあり、リカバリ機構がある時点で、それはもはや単なる「スキル」ではなく、通常のPythonプロジェクトのように見えてくるからです。

さらに2026年4月1日 23:05 のコミット 9e92b8e では、blog-style-suite が scanner.py、builder.py、compressor.py といったモジュールに分割され続けました。この段階に至ると、考え方はすでに非常に工学的なものになっています。

scanner.py: ディスクから記事をスキャンし、構造化された特徴を抽出する役割
builder.py: スコアリング、選別、キャッシュ、ランタイムアセンブリの役割
compressor.py: モデルが関与するいくつかの圧縮ステップを担当する

これは、単にスーパープロンプトを一段書くというアプローチとは、全く異なる考え方なのです。

トークンを節約するのは、玄学ではなく前処理とバッチ化によるもの

このエンジニアリングセットで真に価値があるのは、2026年4月2日19:41のbc4b950だと思います。

あのコミットは非常に率直なことを述べていました。AIの呼び出し回数が約「2000回」から、各プロバイダーで最大「5回」に直接削減されたのです。

どうやって達成したのか？それは「プロンプトをより賢くする」のではなく、事前に処理すべきものを前もって実行することによるものです。

現在のblog-style-suiteのフローは非常に明確になりました：

scanフェーズは純粋にヒューリスティックであり、AI呼び出しは0回。
buildフェーズではまずヒューリスティックなスコアリングを行い、これもAI呼び出しは0回です。
その後、technical / finance / essay / toolingの4つのレーンそれぞれで1回のバッチ選別とラベリングを行います。
最後に作者スタイルの圧縮を1回行います。

これを計算すると、コールドスタートでも最大5回の呼び出しに抑えられます。

さらに重要なのは、この5回が各記事に分散しているのではなく、すでに前処理された高価値な要約材料に集中している点です。

これが前処理が真にトークンを節約する部分です。単に数文字を減らすのではなく、「記事ごとに呼び出す」から「フェーズごとに集中的に呼び出す」というパラダイムシフトなのです。

その後は、キャッシュも整備されました。 builder.pyにはレーンのバッチフィンガープリントがあり、プロバイダーのチェックポイント復元機能があり、さらにローカルモデルのコンテキストのためにreview_pool_per_lane = 12のような縮小化が行われています。少しデータを変更しただけで、パイプライン全体を再実行する必要がありません。

こうした設計は一見派手ではありませんが、一つ一つが非常に実用的です。なぜなら、それらはすべて「同じトークン群を二度と無駄に燃焼させない」という問題を解決しているからです。

現在のデータ構造は、本質的に真に有用なシグナルを圧縮しているものだ

この構造を分解すれば、データ構造も整理されるだろう。私は今、これを3層として理解する方がより良いと感じている。

第1層：`scan.json`

これは共有の原料です。ここには、記事のパス、タイトル、日付、カテゴリ、タグ、冒頭段落、クロージングスタブ、見出し、スクリーニング結果、レーン分類といった構造化されたシグナルが格納されています。これは blog-writer に直接渡されるものではなく、生産側でさらに加工するためのものです。

第2層：`{provider}.source.json`

これはプロバイダーレベルのチェックポイントです。共有された原料に加え、スコアリング結果、レーン選択、フィンガープリント、キャッシュステータスといった中間状態が追加されています。つまり、「加工過程の中間製品」のようなものであり、復元可能、再利用可能、中断して再開できる点が重要です。

第3層：`{provider}.runtime.json` と `published.runtime.json`

これが消費側が真に気にする完成品です。ここには以下のものが保持されています：

author_style
lanes
samples
writer_guide つまり、元々大量にあった過去の記事群を、そのまま利用できるランタイムスタイルアセットとして圧縮したものになります。特に published.runtime.json という公開用のファイルが重要です。blog-writer はこのファイルのみを読み取り、content/post を再スキャンしたり、suite ディレクトリ内の全プロバイダーの完全なイメージを気にする必要がなくなります。この境界線が引かれることで、消費側は軽量化します。執筆モデルが見るのは、もはや原始的な古い記事の山ではなく、すでに前処理された高密度のシグナルとなるのです。

すべてのことをモデルにさせるべきではない

最近、このエンジニアリングにおいて最も正しい判断は、「モデルを多く追加すること」ではなく、「モデルに任せるべきでないこともモデルに投げ渡さないこと」だと感じています。

以下のようなことは、ローカルルールで処理する方が適しています：

frontmatter の解析
冒頭段落の抽出
見出し（headings）の抽出
本人/転載/モデルによる署名の判断
blockquote の比率チェック
 や埋め込みプロンプト、本文の長さといったハードルルールでのフィルタリング

これらの作業をモデルにやらせることは不可能というわけではなく、単に無駄です。

モデルがより適しているのは、曖昧さやトレードオフを含む部分です。例えば、「あるレーンの中でどの記事が現在の論調をよりよく代表しているか」、あるいは「高評価の記事から著者のスタイルタグを抽出する」といった作業です。

そのため、blog-style-suite が真に価値があるのは、「トークンを節約できる」という点だけではなく、人間、ルール、モデルのそれぞれが担当すべき役割を再定義した点にあるのです。

前処理はトークンを節約するためではなく、執筆作業を持続可能にするためである

第2回の結論について、もっと直接的に伝えたい。トークンが潤沢な時は、過去の記事をそのまま使うのはもちろん問題ない。むしろ、本当に1〜2本だけ書くなら、頭を使う量が少ないかもしれない。しかし、このことを長期的なワークフローにしたいと思うなら、前処理は選択肢ではなくなる。なぜなら、前処理をしないと、執筆モデルは毎回古い素材を見直さなければならず、スタイルの維持と記事生成が常に混ざり合ってしまうからだ。 blog-style-suite の意味するところは、このごちゃ混ぜになっているものを分解することにある。システムに見せるためでも、プロジェクト名を増やすためでもなく、blog-writer が軽快に、安定して、「執筆」という一つの動作だけに集中できるようにするためなのだ。ここまで来ると、次のステップの問題は自然とついてくる。すでに生成側が独立した以上、このコストをどのモデルに負わせるべきなのか？ローカルモデル、オンラインモデル、Minimax はそれぞれどの工程に立つべきなのか？この件については、次回の記事 AIでブログを書くという行為は、結局エンジニアリングにする必要がある（三）：ローカルモデル、オンラインモデル、そして Minimax の役割分担で触れることにする。

参考資料

リポジトリコミット：84a06b5dc743f2e9bc6e788d53496a1261bc63ae
リポジトリコミット：9e92b8e6a15d03e6392aff7f3b2dcb0992fe5043
リポジトリコミット：bc4b950cbb13e37d1fdb16a9d23325cfefa6f90e
リポジトリファイル：scripts/blog-style-suite/README.md
リポジトリファイル：scripts/blog-style-suite/style_pipeline/scanner.py
リポジトリファイル：scripts/blog-style-suite/style_pipeline/builder.py
リポジトリファイル：scripts/blog-style-suite/style_pipeline/compressor.py
有効なランタイム：.agents/data/blog-writing/published.runtime.json

作成上の注記

元のプロンプト

$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のコードを基にして、設計思想（どのようにトークン節約を実現したか、データ構造をどう設計したか、核となる設計思想）について説明することができます。トークンが潤沢であれば過去の記事を丸ごと処理できますし、前処理を行うことで多くのトークンを節約できます。

ライティングの骨子（要約）

本稿では、執筆という行為からデータエンジニアリングへと焦点を移し、「なぜモジュール化する必要があるのか」という核心的な問いに答えることを目指した。
冒頭で「生きた歴史の記事をそのまま使える」と認めることで、後続の分割理由に説得力を持たせている。
scan.json、source.json、runtime.json の三層構造を重点的に展開し、単なるアーキテクチャの説明に留まらないようにした。
bc4b950 を中間地点の転換点として配置した。なぜなら、「約2000回から5回へ」という変化が前処理の価値を最も明確に示すためである。
最後に、消費側と生産側を再分離し、次回の記事で扱うモデルの役割分担への布石を打った。

AIがブログを書くという件、結局は工学的なものにする必要がある（1）

Fri, 03 Apr 2026 20:58:02 +0800

昨年、多くの AI に関する記事を書きました。あの頃の最も手間のかかるプロセスは、まず自分でアウトラインや問題リストを整理し、大規模言語モデルに本文を出力させてもらい、その後その内容をローカルの md ドキュメントにコピー＆ペーストし、フロントマター、タグ、カテゴリ、タイトルなどを補完してから公開するというものでした。このプロセスが使えないわけではありませんが、非常に面倒です。本当に時間がかかるのは本文ではなく、本文の外側の繰り返しの作業です。特に最近 Codex を使いすぎてからは、その不自然さがより強く感じられます。それはリポジトリを読み込めるし、ファイルを編集でき、資料を補完できるだけでなく、記事を直接ディレクトリに書き込むこともできます。もし私がまだ手動でコピー＆ペーストを繰り返していると、まるで人間がツールの足を縛っているような気分になります。

この一連の記事は、実は一つのことを伝えたいのです。AI によるブログ執筆は、単なるプロンプト一つに頼るだけでは限界が来ています。今回の記事ではまず blog-writer がなぜ生まれてきたのかを説明します。次の記事では AIによるブログ執筆という事柄は、結局エンジニアリングとしてやる必要がある（2）：blog-style-suite でスタイル学習とトークンコストをどう分離するかを続けます。そして最終回は AIによるブログ執筆という事柄は、結局エンジニアリングとしてやる必要がある（3）：ローカルモデル、オンラインモデル、Minimax は最後にどう分業するかで締めくくります。

本当に面倒なのは、原稿を書くことではなく、あの一連の機械的な動作だ

初期のワークフローは、端的に言えば外部委託されたパイプラインのようだった。私自身がまず問題を明確にするか、あるいは大まかなアウトラインを立てる。モデルが本文を骨子として展開する。その後、人間が戻ってきて残りの公開作業を補完する。

ローカルの md にコピーする
title、date、slug を補完する
タグとカテゴリを入力する
 を補完する
参考資料を整理する
どのディレクトリに配置するかを決定するこの一連の作業は、一つ一つのステップを見れば難しくはないが、繋げると非常に面倒だ。面倒なのは技術的な難しさではなく、それらがすべて機械的であるにもかかわらず、やらざるを得ない点にある。だからこそ、私は後になって、「[コマンドラインベースのAIコーディングインタラクション](/ja/p/command-line-ai-coding-interaction/）」のような変化は、単に「入り口が変わった」だけではないと感じるようになった。AIがリポジトリ内で直接ファイルの読み書きができるようになった今、ブログ執筆がまだ「本文をローカルドキュメントにコピーする」レベルに留まっているとしたら、ワークフロー全体がすでに時代遅れになっているのだ。

blog-writer 最初の価値は文体ではなく、契約を固定化すること

blog-writer の最も初期のノードは、2026年4月1日17:00の 991536a です。gitコミット履歴を見ると、このバージョンではすでに SKILL.md、write_post.py、そして一連の初期のスタイル資料が組み込まれています。

しかし、後から振り返ってみると、このドラフトの最も価値のある点は「AI が私の文体を学んだ」ことではなく、執筆の契約を固定化したことです。

「契約を固定化する」とはどういうことか？

入力には最低限、アウトラインとファクトアンカー（事実の錨点）が必要であること
出力は必ず完全なMarkdown形式であり、未完成品であってはならないこと
frontmatter は人手に頼ることはできないこと
記事はチャットウィンドウ内に留まるのではなく、直接 content/post に配置されること

この点は非常に重要です。なぜなら、プロンプト自体が不安定だからです。「以前のように書いて」と今日言っても、それはトーンが少し似ていると解釈されるかもしれません。明日もう一度同じことを言っても、表面的な構文しか学べないかもしれません。しかし、それが Skill として書かれると、ルールは「その場での即興」から「固定された工程」へと変わります。

後続のいくつかのノードも、実質的にこの契約を補強し続けています。

2026年4月2日22:54の 8eb735a では、著者フィールド、執筆に関する注記、元のプロンプトなどが固定されました。この段階に至ると、ブログ記事の完成は単に「本文が書き終われば完了」ではなくなり、メタ情報、トレーサビリティ（追跡可能性）、公開される注記までが標準化されたのです。

したがって、blog-writer の最初の価値は、モデルをより文章を書くのが上手に見せかけることではなく、執筆という行為自体に、再現可能な境界線を持たせたことなのです。

シリーズ形式は、実は執筆の契約をさらに一歩進めたもの

単発の記事で安定して書けるようになると、次の問題がすぐに浮上します。あるテーマは、そもそも一つの記事に詰め込むのが適していません。無理に詰め込もうとすると、結局は情報量が多すぎてメインの筋が散漫になり、どの点も深く掘り下げきれない長文になってしまいがちです。これが、2026年4月2日 23:55 の 1a5604e が重要だった理由です。あの時、シリーズ形式と write_post_series.py をまとめて追加しました。記事間は relref で繋ぎ、一括書き込みの際に統一的に置換するようにしたのです。これは単なるファイル生成スクリプトの小さなアップグレードに見えますが、実際はそうではありません。それは一つのことを示しています。執筆の工程化は、「この一篇をどう生成するか」だけを考える段階から、「この一連のコンテンツをどう安定して配置し、順序をどう保証し、サイト内で相互にリンクさせるか」という視点に移ってきたということです。翌日の2026年4月3日 09:29 の 04dccb9 は、この件をさらに一歩進めました。シリーズ記事のタイムスタンプが分単位で増加し、もはや共通の時間を使用しないようにしたのです。この変更は非常に小さいものですが、エンジニアリング的な深みがあります。なぜなら、Hugoのリストページ、前後の記事リンク、シリーズの順序といった「実際の問題」を解決しているからです。端的に言えば、シリーズ形式というのは、格好良く見せるためではなく、「複数の記事をまとめて公開する」という作業が、もはや手動でのフォローアップに頼らなくて済むようにするためなのです。

しかし、単一のスキルだけでは、後でトークン制限にぶつかることになる

問題はここにあります。文体学習を真剣に行い始めると、blog-writer のコンテキストがすぐに肥大化します。ただ書くだけでなく、以前あなたのように書くことも期待するわけです。最も自然な方法は、過去の記事も一気に詰め込むことです。これなら、一度だけは実行できます。しかし、たまに記事を書くだけではなく、長期的なワークフローにしたいと思うと、すぐに問題が発生します：

トークン消費量が高い
毎回同じ古い記事を繰り返し与えることになる
モデルの注意力が古い材料によって希釈される
原稿執筆とスタイル維持が絡み合い、どちらも容易ではないここから、私はblog-writerは、すべてを任せる側（生成側）というよりは、消費する側として使う方が適していることに気づき始めました。原稿執筆という動作は、できるだけ軽く、直接的に、そしてできれば公開されたバージョンのみを参照するようにすべきです。一方、スタイルデータの生成方法、選別方法、圧縮方法は、別の生産側のパイプラインの問題なのです。この判断が、私を次のステップへと導き、それがAIでブログを書くという件は、結局エンジニアリングにする必要がある（2）：blog-style-suiteでスタイル学習とトークンコストをどう分離するかへと繋がりました。

まずプロセスを安定させてから、スタイルやモデルについて語る資格が生まれる

今振り返ると、blog-writer が生まれたのは、私が突然ブログライティングアシスタントを作りたいと思ったからではない。むしろ、これまでのワークフロー自体が、新しい働き方に合わなくなってきたことが原因だ。 Codex のようなツールがインターネットに接続して資料を補完できたり、リポジトリ内での読み書きができたり、スクリプトを直接呼び出せるようになった場合、「ブログを書く」という行為は「本文をローカルドキュメントにコピーする」という段階で止まっているべきではない。この部分を自動化しなければ、かえって全体のプロセスの中で最も非効率な工程になってしまう。そのため、最初の記事の結論はここまでとする。 blog-writer が最初に解決したのは、文体ではなく、公開作業における反復的な手作業だった。このレイヤー（層）という契約がなければ、後からトークンやデータ構造、ローカルモデルについて語っても、実際には根拠がない。

参考資料

リポジトリコミット：991536a237d04aba7c44dec501b3d98c644040c8
リポジトリコミット：8eb735aa8448c97deb2af1ea46b86772008fa9e3
リポジトリコミット：1a5604e7e6ce0a13f260fcbb8c2c1d964cdd0892
リポジトリコミット：04dccb98c55a6ea3b81408012b33a6219cf8ab77
リポジトリファイル：.agents/skills/blog-writer/SKILL.md
リポジトリファイル：.agents/skills/blog-writer/scripts/write_post.py
リポジトリファイル：.agents/skills/blog-writer/scripts/write_post_series.py

作成上の注記

元のプロンプト

$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 のコードを基にして、設計思想や、どのようにトークン節約を実現したか、データ構造はどう設計したか、といった核となる設計思想について説明することができます。トークンが潤沢であれば過去の記事を丸ごと処理できますし、前処理を行うことで多くのトークンを節約できます。

ライティングのアイデア概要

最初の記事はワークフローのトリガーポイントに焦点を当て、トークンとモデルの役割分担を急ぎすぎず、3つの記事でメインテーマを奪い合うのを避ける。
「本文自体は難しくないが、公開前後の一連の機械的な作業が面倒である」という判断を重点的に残した。
991536a、8eb735a、1a5604e、04dccb9 などのノードを通じて、「プロセスを契約化する」ことを実際のGitの進化に落とし込む。
シリーズ形式はこの記事で取り上げることで、ブログ執筆が単発の記事生成から一連の成果物（セット）へと移行したことを示すためである。
最後に意図的に問題をトークンウォールに引きつけ、次の記事でのデータエンジニアリングと前処理のための布石とする。

過去2年間のAIに関する記事を振り返った結果、次に書くべきテーマとしてこの8つを選びました。

Mon, 30 Mar 2026 22:20:00 +0800

最近、ブログ内の過去2年間にわたるAI関連の記事を遡って読み返したところ、内容は当初の「あるモデルが使えるかどうかの単純な体験談」という段階から進化し、より明確な一本の筋道を描いていることに気づきました。それは、**「AIがどのようにして私の開発ワークフローに真に入り込み、どのような効率性、コスト、そして新たな制約をもたらしたか」**という点です。

ここでいう「ここ2年」は、現在の日付から遡って考えると、おおよそ2024-03-30から2026-03-30の間を指します。実際に読み返すと、非常に明白な現象として、2024年には真に意味のあるAIテーマの記事がほとんどなく、集中的な発信は2025-01になってから始まったという点です。この事実はそれ自体が興味深いです。これは私にとって、AIが最初から安定した利用期に入ったわけではなく、仕事や執筆の中で徐々に浸透し、適切なツールやタスクの形に遭遇してから、継続的な記録として形成されていったことを示しています。

この2年間のAIに関する記事は、大まかに3つの段階に分けることができます

フェーズ1：ツールの試用、まず使えるかどうかの確認

このフェーズを代表する記事には以下のようなものがあります：

『Cursor AI 開発環境（IDE）の試用』
『ollamaによるdeepseek-R1のローカルデプロイ』
『コードを書かず、自選股モジュールを設計・開発する』
『AIの発展は2年間：Dockerリリース前の状況に似ている』このフェーズにおける中心的な問いは非常に素朴です。「AIは本当に私の代わりに作業をしてくれるのか？」 当時の関心事は、よりツールレベルに留まっていました：
IDEの使い勝手が良いか
ローカルへのデプロイが動作するかどうか
モデルが生成したコードで時間を節約できるか
複雑な要求に直面した際、AIは途中で行き詰まらないか振り返ってみると、このフェーズの記事群は、その後の本格的な利用に向けての「土台作り」のようなものです。多くの結論は今でも当てはまります。例えば、「AIは基本的な開発効率を明らかに向上させるが、複雑なタスクには依然として手動での分解が必要である」「ローカルモデルは試すには良いが、実際の高頻度ワークフローに組み込むには、安定性と速度が鍵となる」といった点です。

第二段階：ワークフローへの導入と、それに伴う副作用の出現

この段階を代表する記事は以下の通りです：

『AIを使いすぎると、ちょっとした後遺症が出る』
『Claude 4リリースに伴い試みた開発：hugoタグ、超リンク翻訳アシスタント』
『最近の大規模モデルに関する使用経験』
『ByteDance AIコーディングの新パラダイム SOLO』

ここまで来ると、AIはもはや「たまに試すツール」ではなくなり、直接的に関与し始めるようになります。

ブログツールの開発チェーン
翻訳キャッシュとバッチ処理フロー
UIデザインとコードの往復作業
モデルの役割分担とシナリオ選択

同時に、問題意識もより具体的になってきます。以前は「AIはコードを書けるのか？」という疑問でしたが、その後は以下のような疑問に変わってきました。

コードは書かれたが、どうやって受け入れ（検証）するのか？
文章は生成されたが、リアリティがあるのか？
ドキュメントは同期更新されたが、自分自身は本当に理解したのか？
ツールはどんどん強力になるが、人間の思考の負荷は低下しているのではないか？

これも私がこの一連の記事の中で最も価値があると感じる部分です。「AIはすごい」という空論よりも、少し居心地の悪さを伴うような記録の方が、むしろ真実味を帯びているからです。

第3フェーズ：単一ツール体験からプロトコル、ワークフロー、安定性、コストへ

この段階を代表する記事には以下のようなものがあります：

「コマンドラインベースのAIコーディングインタラクション」
「プロトコル制約からインテリジェントな解放へ：MCPとSkillの深掘り比較」
「ヘビーAIプログラミングの日々」
「低価格API中継地点の終焉：3月のLLM体験と不可能性の三角関係」この段階になると、関心事が明確に高度化しています。もはや「どのモデルがより賢く回答するか」というレベルではなく、以下のような点に焦点が当たっています。
ターミナルインタラクションとIDEインタラクション、どちらが継続的な開発に適しているか
MCPやSkillといった能力拡張方式には、具体的にどのような境界線の違いがあるのか
ヘビーAIプログラミングを行う際、人間はどの部分で介入すべきか
コスト、安定性、品質の間で、どのように現実的な選択をするかこうしたトピックはもはや単なる製品レビューではなく、ワークフロー設計に近づいています。これが現在ブログにおけるAIテーマの中で最も安定しており、識別性の高いラインとなっています。

この記事群の最大の強みは、トレンドを追うことではない点です。

振り返ってみると、ブログに既に存在するAIの記事で、真に差別化できるポイントは、あなたが他の人より早く特定のモデルを書いたからでも、パラメータやランキング、ベンチマークスコアをより網羅的に書いたからでもなく、以下のいくつかの点にあります。

1. すべて実際の利用シーンから生まれたもの

自選股モジュール、ブログ翻訳ツール、コマンドラインでのコーディング、APIの中継地点の試行錯誤記録など、ほとんどの内容は思いつきで書かれたものではなく、実際に使用する中で問題に直面した後に書いたものです。このようなコンテンツの良い点は、空虚になりにくいことです。

2. 関心は「どうやってAIをプロセスに組み込むか」にある

多くのAIに関する記事はモデルの能力に焦点を当てがちですが、現在の手持ちの記事群はむしろ以下の点に関心を寄せています：

タスクの分解方法
プロジェクトへの組み込み方
ドキュメントの保守方法
コンテキストの制御方法
異なるモデル間での役割分担の方法こうした内容のライフサイクルは、単なるモデル評価よりも長い傾向があります。

3. 副作用とコストを認識し始めた段階

『AIを使いすぎると後遺症が出る』から『格安APIの中継地点の終焉』に至るまで、実は非常に一貫した思考の流れが形成されています。

AIは効率を向上させる
しかし、人間の検索や思考の習慣を変えてしまう
安い＝本当に節約できているわけではない
品質、安定性、コストパフォーマンスが良いというものは同時に成立するのが難しいこのような判断は、個人的な利用経験から積み重ねたものであり、単にネット上の意見を繰り返しているわけではありません。

しかし、いくつかの明白な情報の欠落点もあります

既存の記事はすでに骨子がありますが、もし書き進めるのであれば、いくつか目立ったギャップがあると感じています。

1. 体系的な「受け入れ方法論」の欠如

これまでに多くのAIプログラミング体験について記述し、単体テスト、性能テスト、ドキュメント同期についても触れてきましたが、「AIが書いたものをどう検証するか」という点を完全に解説した記事がまだありません。

2. チーム視点の欠如

現状では、ほとんどが個人開発や個人のワークフローの視点に留まっています。この視点は優れていますが、さらに記述を進める場合、以下のように拡張できます：

複数人での共同作業時にAIによる修正範囲をどのように制限するか
コードレビューにおいてAI生成コードをどう評価するか
ドキュメント、コミットログ、テスト記録などをどのように連携させるか

3. セキュリティと権限境界に関する議論の欠如

最近のトレンドはますます明らかになってきており、AI は単なるチャットボックスではなくなり、以下のものを制御し始めています：

ターミナルコマンド
リポジトリの読み書き
ブラウザ操作
サードパーティツール呼び出し能力が強くなるほど、権限境界について記述する価値が高まります。

4. 「長期知識ベース」の視点の欠如

現在、記事には翻訳キャッシュ、スラッグ、タグといった基本的な機能はありますが、「もしブログ自体が個人のナレッジベースであるとしたら、それをAIによる消費、検索、加工に適したコンテンツ資産としてどのように整理するか」という点について、体系的な記述がまだなっていません。

次に書くのに最適だと考える 8 つのテーマ

以下の 8 つの分野は、「現在の執筆スタイルに最も合致しているか」と「独自の内容を書きやすいか」という観点から並べました。

1. AI プログラミングの受け入れ（受入）体制をどう構築するか

これが私が最優先で執筆することを推奨する記事です。以下の内容に重点を置くと良いでしょう：

どの変更に対して単体テストを追加する必要があるか
どのモジュールでリグレッションテストを実行する必要があるか
どのリファクタリングで性能比較が必要か
どのドキュメントを同期的にメンテナンスすべきか
人間によるレビュー（review）時に重点的に確認すべき点この記事が完成すれば、後続の多くのAIプログラミングに関する記事から繰り返しリンクさせることができます。

2. MCP が真に役立つシナリオは、「接続できる数が多いこと」ではない

現在、MCP はますます注目されていますが、ほとんどの議論は概念的なレベルに留まっています。より書くべきなのは以下の点です：

どのツールを接続することで本当に効率が向上するか
単に見た目がクールなだけで、実際には不要なものは何か
ローカルファイル、ドキュメント、イシュー、監視データ、デザイン稿など、どれから優先的に連携すべきか
プロトコル化された接続と「長いプロンプトを詰め込む」のとでは、具体的にどのような違いがあるのか

3. Claude Code、Codex、Gemini CLI、国産CLIモデルの横断的な実戦比較

単に「どれが良いか」と書くのではなく、統一されたタスクセットで横並び比較を行います。例えば、以下の項目を固定して比較します：

要件分解能力
指示追従度
コード修正範囲の制御性
テストコード補完能力
ドキュメント同期能力
コストと待ち時間このような記事は読者が最も参考にしやすい形式です。

4. AI プログラミングにおけるコンテキスト管理

多くの場合、モデルが弱いのではなく、コンテキストが汚れている、長すぎる、または漂っていることが原因です。このテーマは特化して書くことができます：

いつコンテキストをクリアすべきか
いつ新しいスレッドを開くべきか
いつタスクを分割すべきか
いつ複数のエージェントを並行させるのが適切か
どのような状況で現在の状態を手動で再要約する必要があるかこのトピックは非常に具体的であり、自身の実際の事例と結びつけやすいものです。

5. IDE からターミナルへ、そしてマルチエージェント協調へ

過去1年で、AIプログラミングインタラクションの焦点は明らかに変化しました。以前はIDE内での補完、チャット、局所的なコード修正が中心でしたが、現在ではますます多くのツールが以下の点を重視し始めています：

ターミナル操作（ターミナルインタラクション）
リポジトリ全体を理解すること（リポジトリレベルの理解）
マルチスレッドなコンテキスト管理
並行エージェント
worktreeによる隔離開発このテーマは、これまでのCursor、Trae、Claude Code、Codexといった記事群を結びつけるのに適しています。

6. AI プログラミングのセキュリティ面が拡大している

この方向性は書き甲斐があり、まだ十分にカバーされていません。以下の角度から切り込むことができます：

コマンドの自動実行に伴うリスク
サードパーティのMCPサービスにおける信頼境界
プライベートリポジトリや機密情報の漏洩問題
プロンプトインジェクションと悪意のあるコンテキスト汚染
自動化スクリプトと人間による確認の境界線単に「AI は非常に優秀だ」という内容だけでは、記事は徐々に似通ってしまいます。セキュリティの境界線を盛り込むことで、コンテンツの階層性が格段に高まります。

7. ローカルモデルの真の立ち位置

以前は「ローカルモデルが動くか」という点に焦点が当たりがちでしたが、今より重要視すべきなのは以下の点です。

どのようなタスクに適しているか
どのようなタスクに向いていないか
プライバシー、オフライン動作、低コストといった利点がいつ真に成立するのか
いつからローカル案を固執することが、逆に時間の浪費になるのかこれらは単なるデプロイメントチュートリアルよりも、より継続的な価値を持ちます。

8. ブログをAIフレンドリーなナレッジアセットとして整理する方法

この方向性は、既存のブログシステムと最も密接に結びつきます。以下のような内容が書けます：

slug、タグ、要約、カテゴリの統一的な設計方法
多言語コンテンツにおけるリンクドリフトの削減方法
記事のメタデータがその後の検索をどのように支援するか
過去の記事をAIによる検索、要約、引用に適した形にする方法この記事を書けば、AIというテーマを扱いながら、同時にブログシステム全体に貢献することができます。

今後注目すべきトレンド

最近の業界の変化がいくつかあり、今後のトピック選定判断にも影響を与えます。

第一に、AIプログラミングは、「補完ツール」から「エージェントワークフロー」へと、ますます明確に移行しています。CodexやClaude Codeのような製品が強調しているのは、単発の回答ではなく、タスクの分解、ツール呼び出し、並列処理、そしてコンテキストの継続的な維持です。

第二に、MCPのようなプロトコル化された接続方式は、「新しい概念」から「インフラストラクチャ」になりつつあります。今後真に価値のある記事は、単にプロトコルの定義を再説明するのではなく、**「どの接続シナリオが本当に有効で、どれがただ先進的に見えるだけなのか」**を明確に記述することになるでしょう。

第三に、デザイン稿、ドキュメント、コード、コマンドライン間での往復が増えています。以前はツール間で分断されていましたが、今AIはそのリンクを繋げようとしており、これは「ワークフロー設計」が「モデルの羅列（ランキング）」よりも長期的に価値があることを意味します。

第四に、安定性、コスト、権限のリスクは消えません。むしろ、モデルの能力が強くなるほど、これらの問題はより重要になります。

最終的な考察

もしAIについて書き続けるとしたら、私が最も堅持すべきだと感じることは、毎回モデルがリリースされるたびにベンチマークを行うことではなく、より具体的な問題に焦点を当てて掘り下げることです。

「AIはどのようにして実際の開発や執筆のワークフローに段階的に組み込まれていくのか？それはどの部分で真に効率を向上させ、またどの部分で問題を人間に差し戻しているのか。」

この論点は、あなたはすでに書き出していますが、まだ完全に形になっていないだけです。次に最も適切なアプローチは、テーマを広げることではなく、「実用ツール」「プロセス設計」「境界制御（限界設定）」「長期的な知識資産」というこれら4つのサブラインに沿って掘り下げることです。このように書いたものは、時間が経つにつれて、すぐに陳腐化するトレンドの記録ではなく、自分自身のものとして蓄積されやすくなります。

ワークフロー on 向叔の手帳

AIがブログを書くという件は、結局エンジニアリングにする必要がある（2）

最初の一番自然な発想は、過去の記事をそのまま与えることだ

これがデータモジュールとデータ生成モジュールを分離しなければならない理由です

トークンを節約するのは、玄学ではなく前処理とバッチ化によるもの

現在のデータ構造は、本質的に真に有用なシグナルを圧縮しているものだ

第1層：scan.json

第2層：{provider}.source.json

第3層：{provider}.runtime.json と published.runtime.json

すべてのことをモデルにさせるべきではない

前処理はトークンを節約するためではなく、執筆作業を持続可能にするためである

参考資料

作成上の注記

元のプロンプト

ライティングの骨子（要約）

AIがブログを書くという件、結局は工学的なものにする必要がある（1）

本当に面倒なのは、原稿を書くことではなく、あの一連の機械的な動作だ

blog-writer 最初の価値は文体ではなく、契約を固定化すること

シリーズ形式は、実は執筆の契約をさらに一歩進めたもの

しかし、単一のスキルだけでは、後でトークン制限にぶつかることになる

まずプロセスを安定させてから、スタイルやモデルについて語る資格が生まれる

参考資料

作成上の注記

元のプロンプト

ライティングのアイデア概要

過去2年間のAIに関する記事を振り返った結果、次に書くべきテーマとしてこの8つを選びました。

この2年間のAIに関する記事は、大まかに3つの段階に分けることができます

フェーズ1：ツールの試用、まず使えるかどうかの確認

第二段階：ワークフローへの導入と、それに伴う副作用の出現

第3フェーズ：単一ツール体験からプロトコル、ワークフロー、安定性、コストへ

この記事群の最大の強みは、トレンドを追うことではない点です。

1. すべて実際の利用シーンから生まれたもの

2. 関心は「どうやってAIをプロセスに組み込むか」にある

3. 副作用とコストを認識し始めた段階

しかし、いくつかの明白な情報の欠落点もあります

1. 体系的な「受け入れ方法論」の欠如

2. チーム視点の欠如

3. セキュリティと権限境界に関する議論の欠如

4. 「長期知識ベース」の視点の欠如

次に書くのに最適だと考える 8 つのテーマ

1. AI プログラミングの受け入れ（受入）体制をどう構築するか

2. MCP が真に役立つシナリオは、「接続できる数が多いこと」ではない

3. Claude Code、Codex、Gemini CLI、国産CLIモデルの横断的な実戦比較

4. AI プログラミングにおけるコンテキスト管理

5. IDE からターミナルへ、そしてマルチエージェント協調へ

6. AI プログラミングのセキュリティ面が拡大している

7. ローカルモデルの真の立ち位置

8. ブログをAIフレンドリーなナレッジアセットとして整理する方法

今後注目すべきトレンド

最終的な考察

第1層：`scan.json`

第2層：`{provider}.source.json`

第3層：`{provider}.runtime.json` と `published.runtime.json`