エージェント駆動のワークフロー向けインフラを構築してきた。単にコードを速く書かせるためではない。エージェントが実際に私のシステムを操作するために。
今のところ五つのツール。すべて同じパターン、同じ問いから：エージェントにコードを書かせるためではなく、エージェントが使うために設計されたソフトウェアとはどういうものか？
どこから来たか
複雑なゲームのAIを設計していた。そのAIの意思決定プロセスは冗長なログを生成した。何千行もの推論トレース、状態遷移、評価スコア。特定のシナリオでAIがなぜ悪い決定をしているかをデバッグする必要があった。
loglerの前は、ワークフローが苦痛だった。ログの塊をClaudeのコンテキストウィンドウにペーストして調査を依頼する。冗長な出力がトークンを猛烈に消費し、Claudeは調査の途中でスレッドを見失い、再起動して再説明して再調査する。ループ。各セッションは新鮮なスタートだった。調査状態を永続化する方法がなかったから。
苛立たしい点：情報はログに全部あった。全部。Claudeはただそこに効率的にアクセスできなかった。生の出力には多すぎるトークン、特定のスレッドをクエリする方法なし、異なるゲームシステム間のログエントリの相関なし。非常に高価な grep としてClaudeを使いながら、ログ調査ツールの仕事を手でやっていた。スレッドは明らかだった。エージェントがそれを引き出せるインフラが必要だっただけ。
だからloglerを作った。サイドプロジェクトとしてではない。時間の無駄を止めるために必要なインフラとして。
-lerスタック全体のパターン
クールなサイドプロジェクトにするつもりは全くなかった。解決すべき実際の問題があった。必要なものを作った。何度も元を取った。
logler: Claudeが冗長なログ出力でコンテキストを消費していた。調査ステップあたり何千トークンも。そしてスレッドを見失い最初からやり直す。Loglerはトークン予算コントロール付きの構造化アクセスをエージェントに提供する。count フォーマットは全出力の513,019バイトに対して202バイトを返す。これは僅かな改善ではない。調査できるエージェントと溺れるエージェントの違いだ。
procler: Claudeがプロセス状態を確実にクエリできなかった。ps aux 出力をスクレイピングするのは厄介で、エージェントは推測し、間違え、また推測する。Proclerはそれをし返す：pid、uptime、state。人間はWebUIを得る。エージェントはCLIを得る。両方がファーストクラス。「Claude Codeはファーストクラスの市民」というのが最初からの設計制約だった。後付けの機能ではない。
sqler: ネイティブにJSONを返すデータレイヤーが必要だった。人間向けORMにボルトで止めた --json フラグの後付けではなく。エージェントワークフローのためのJSONファーストの永続化。
qler: タスク調整ツール。同じ哲学。
全てに共通するパターン：設計制約としてのトークン効率、プライマリインターフェースとしての構造化出力、エージェントがクエリできる状態、再起動をまたぐ調査のためのセッション永続化。機能ではない。一つの問いの帰結：「エージェントがこれを操作するのに何が必要か？」
注：記事の残りではloglerを他より多く例として使うが、proclerとqlerも同様に位置付けられている。sqlerは一種の接着剤/ブリッジ/データバックエンド/マイクロORM/何かだ¹
ファクトリー視点
2026年にもまだ同じ議論を（どういうわけか）している人がいる：「LLMは確率論的ブラックボックスだ。」[まるでそれが致命的欠陥であるかのように]
結構。人間も確率論的ブラックボックスだ。それでもファクトリーを作り上げた。
トヨタ生産方式のもとで価値の流れを動かして分析した。プロセスオーナーシップ。標準作業。ポカヨケ。² スタック全体。ここから直接適用できること：
バリューストリームマッピング → エージェントがトークンを無駄にしている場所、コンテキストを失っている場所、決定を再導出している場所を特定する。ログ調査にはサイクルタイムが計測できる。トークンの無駄は計測できる。コンテキスト枯渇は計測できる。ストリームを最適化すれば、素晴らしい価値が反対側から出てくる。
標準作業 → CLAUDE.md、ロードマップの規律、必須プランモード。エージェント操作のための文書化された再現可能なプロセス。フィーリングではない。システムだ。
日常管理 → CLAUDE.mdの更新、ポストモーテムの実施、システムの欠陥の修正。Claudeがやり直しを引き起こしたとき、システムが失敗した。どんな失敗も最終的にはシステムの失敗だ。
ポカヨケ → エラーが明らかになるか不可能になる出力を設計する。構造化フォーマットはパース失敗を早期に検出する。型安全なインターフェースはカテゴリエラーを防ぐ。セッション状態は調査の損失を防ぐ。
核心的な洞察は複雑ではない：LLMが人間であり、コードが機械だ。 決定論的LLMを待っているのではない。トヨタが決定論的な人間を待たなかったように。プロセスコントロールは変動性を排除しない。失敗率を下げ、一貫性を高め、エラーを検出し、回復を可能にする。
バリューストリーム思考vs機能思考
機能思考：「エージェントがパースできるよう --json フラグを追加しよう。」
バリューストリーム思考：「ログ調査にはボトルネックがある。冗長な出力のトークン無駄。調査中のコンテキスト枯渇。再起動でのセッション状態消失。サイクルタイムは？無駄はどこ？全体のストリームをどう最適化する？」
-lerスタックはその二番目の問いから来た。「クールなログツール」でも「プロセスマネージャー」でもない。それぞれがバリューストリーム分析から始まった。ボトルネックを特定し、無駄を計測し、高コストなステップを排除する。ツールは思考の帰結であり、その逆ではない。
結果：エージェントはコードを書き、proclerでプロセスを起動し、loglerでログをチェックし、反復する。インフラがワークフローをサポートし、それと戦わない。
Paul DixはInfluxDataでの検証インフラの構築について書いている。検証システム、フィードバックループのエージェント、組織的観点。Simon Willisonはコーディングエージェントのための開発者の規律を記録している。テストパターン、実用的なワークフロー。どちらも重要な仕事をしている。私の角度はバリューストリームだ。異なるアプローチ、似た結論：機械を作る機械を作れ。
エージェントファーストは人間最後を意味しない
エージェントファースト設計は人間を害するか？
正しくやれば、しない。
LLMは複雑さをうまく扱える。CLIにフラグが百万個あっても？Claudeは対処する。ffmpegの構文を覚えたくない（実際よく使うなら覚えるかもしれないが）。Claudeにやらせるだけ。動画のリサイズ、サンプルレートの変更、何でも。エージェントが複雑さを処理する。あるいはもっと良いのは、再実行できるbashスクリプトを書いてくれること。
考えるべきときに考えろ。³ フラグの暗記に思考を無駄にするな。
同じエンジン、異なるインターフェース。エージェントは構造化JSONを得る。人間はダッシュボードとリアルタイム更新を得る。どちらも他を劣化させない。どちらもファーストクラスだ。
旅：失敗そして改善
監視ダッシュボードを作っていた。データは既にあった。データを取得するパスも既にあった。単純な配線作業。
Claudeはデータ接続を全部ゼロから作り直した。完全に機能するものが既にあるのに、ダッシュボード専用の実装を。一部はただ悪かった。間違ったアプローチ、不必要な複雑さ。一部はもっと悪かった：本物のデータに繋がっているように見えるが、実際には何にも繋がっていないブラウザJavaScript。美しいダッシュボード。偽の配管。Claudeは既存のインフラが再利用するには綺麗ではないと判断した。
信頼しすぎ、構造が足りなかった。「既存のデータパスを使え」と指定するロードマップなし。再発明が起きる前に捕まえるプランモードなし。失敗はClaudeがダッシュボードを苦手だったことではない。失敗は、機能しているものを作り直すことを許したシステムだった。
旅の全体は失敗そして改善だ。それが日常管理だ。それが継続的改善だ。それがファクトリーの動き方だ。Claudeがやり直しを引き起こしたとき、Claudeを責めない。ミスを許したシステムを修正する。
次へ
今のエージェントはセッションベースだ。実行を開始し、作業し、終了する。
地平線：常時稼働エージェント。監視する。調査する。人間をループの外に置いたまま応答する。それには、コンテキストウィンドウを枯渇させないログ調査、人間の解釈なしにクエリできるプロセス状態、再起動をまたいで持続する調査セッション、エージェントが拾って続けられるタスクキューが必要だ。あらゆる場所での構造化出力。
ほとんどのプロダクションシステムはこれに対応していない。ログは人間が読めてトークンが高い。プロセス管理は出力をスクレイピングする。タスク調整はNotionのドキュメントだ。インフラは画面を読む人間のために作られた。自律的に操作するエージェントのためではない。
自分自身のCLIを監査し始めた。この出力は人間が解釈する必要があるか？目に最適化されているか、パースに最適化されているか？構造化出力は後付けとして存在するか、それとも設計の目的か？
ログを見た。プロセスマネージャーを見た。タスクキューを見た。デバッグツールを見た。
問いかけた：エージェントがこれを操作するのに何が必要か？
そして、より良い答えを作った。
終わりに
今起きている会話はエージェントによるコード生成だ。結構。重要だ。
私がしたい会話：統合されたバリューはどこにあるか？
マネジメントはExcel統合とカスタマーサービスボットを見る。ツールメーカーはコード生成とオートコンプリートを見る。どちらも本物だ。どちらもここにあるものの一部にすぎない。プロダクションシステムのオペレーターとしてのエージェント。彼らのために設計されたインフラ。LLMワークフローに適用されるプロセスエンジニアリング。バリューストリームは「関数を書いてくれ」で終わらない。
作ったのは、スレッドがそこにあったから。プロセスエンジニアリングのレンズ、バリューストリーム最適化の本能、変動するコンポーネントが構造化されたシステムの中で機能するのを何年も見てきた経験。同じ原則。違うワーカー。スレッドを引いた。
ツールを監査せよ。トークン効率のために設計せよ。機能ではなくバリューストリームで考えよ。インフラにもっと要求せよ。機械を作る機械を作れ。
リンク：
- Paul Dix: Build the Machine That Builds the Machine
- Simon Willison: Agentic Engineering Patterns
- logler on PyPI
- procler on PyPI
- sqler on PyPI
- qler on PyPI
¹ これが奇妙なのは分かっているが、SQLが好きでPostgresが好き。でもオーバーキルも好きじゃない。
² ミスプルーフィング。エラーが明らかになるか不可能になるようにシステムを設計する。
³ それがいつかを知っているのはあなただけだ。