要約
NalyはCodex CLIを、定期実行AI作業の制御プレーンとして使用しています。各cronエントリは、ウェブ検索と厳密な出力契約を備えた境界付きのアシスタントタスクを起動するチェックイン済みスクリプトを実行し、下流の公開、再実行、再試行のために検証済みJSON成果物を書き込みます。これにより、モデルの作業は可変的な対話ワークフローではなく、同一コマンド、明示的スキーマ、明示的成果物を持つ運用パイプラインとして振る舞います。2026-06-25現在、この違いが成長に重要なコンテンツ基盤の信頼性上の優位点です。
Naly内の配置
Nalyではすでにディスカバリー、継続率、配信ワークフローを軸にしたGSTの優先事項が稼働しており、このパターンはその実行レイヤーに直接適合します。
- Cronジョブは各ユースケースにつき
tsx1つのスクリプトを呼び出すため、実行ごとに即席のシェル断片ではなく、バージョン管理されたコード内に留まります。 - Codex CLIが推論と取得を担当し、Nalyがオーケストレーション制御（スケジュール、再試行、ロック、永続アーティファクト）を管理します。
- 構造化出力は、Next.js、React、Drizzle ORM、Neonで構築された下流システムに、スキーマ推測なしで供給されます。
- 外部ログと実行メタデータは以下の下に書き込まれます
NALY_LOG_ROOT。これにより、プロセス出力バッファリングに依存せず、事後検証を再現可能にします。
要旨はこうです。プロダクション用途では、LLM品質はシステムの半分にすぎず、もう半分はそのLLMを囲む決定論的な境界です。
技術的メカニズム
1) 契約優先のワーカーエントリーポイント
各タスクは3つの不変入力から開始します。
- コード化されたプロンプトテンプレートとタスク意図。
- 検証対象となる応答スキーマ。
- 実行エンベロープ（
run_id,source_query,attempt,env）、APIコール前に永続化します。
Nalyは対話モードではなくcronからbatchモードでCodex CLIを呼び出します。Codexはローカルコーディングエージェントとして文書化され、オープンソース配布と継続的リリースがある単体CLIとして提供されているため、スクリプト環境で実行できます。 Codex CLI, OpenAI Codexリポジトリ。
2) 構造化出力が譲れない理由
OpenAIのstructured-outputガイドは、パーサー対応のスキーマ抽出と、機械向けパイプラインに必要なstrictモード動作を説明しています。Nalyでは、モデル出力は最終真実ではなく中間成果物として扱われるため、JSON契約が信頼性を強制する位置になります。
- 必須フィールド（headline、evidence list、confidence、citations、failure reason）
- デフォルト値付き任意フィールド
- 数値のconfidenceと上限・下限付きenum
- パーサーの失敗は明示的な実行エラーとして表面化させ、静かに自動修正されたテキストとして扱いません。
3) 同時実行制御付きCron-to-agentライフサイクル
Cronは標準的な5フィールドの時間指定に従って予約行を実行し、条件が一致するときにコマンドを起動します crontab。 本番安全性のため、Nalyは以下を追加します。
- ロックガード（タスクごとに1つのアクティブ実行）
- 冪等な実行キー
- ジッター付きの上限付き再試行ポリシー
- 各フェーズごとの外部ログ取得
- 実行後の状態更新はDrizzle/Neon管理のDBテーブルに記録します。
flock はまさにこのガードレールパターン向けに設計されており、ロックを取得して重要セクションを実行し、既にロック中ならクリーンに終了します。 flock。ロック状態がファイル記述子ベースで管理されるため、重複するcron時間枠は状態を破損させることなく明示的に拒否されます。
4) このパターンにおけるMCPの意味
Model Context Protocolは、JSON-RPC、機能ネゴシエーション、構造化ツール呼び出しを用いて、ホスト/クライアント/サーバーのツール契約を形式化します。 MCP。Nalyでは、MCPスタイルの境界が暗黙的な結合を低減し、Web検索を自由形式のシェルレベル挙動ではなく、明示的な機能を持つ制御されたツールインターフェースとして表現できます。
研究文献の示唆
最近の研究では、信頼性は単なる生の能力と同義ではないことが示されています。AI Agent Reliabilityの論文は、タスク精度と実行間一貫性との間に大きなギャップがあることを報告し、運用品質評価のために明示的な信頼性次元（consistency、robustness、predictability、safety）を提案しています。 AI Agent Reliabilityの科学を目指して。これはNalyのrun-state-first設計を支持します。実行が成功しても明確な成果物を使って再現できない場合、それは本番グレードとは言えません。
構造化出力について、ToolPRMは構造化ツール呼び出しの挙動には明示的な監視が必要であり、最終結果だけでなく内部の関数呼び出しプロセスをモデリングする場合に改善効果が特に高まると論じています。 ToolPRM：構造化された出力の関数呼び出し向けFine-Grained Inference Scaling。これはNalyのスキーマファースト実行ループと整合しています。品質ゲートは内容の流暢さだけでなく、インターフェース境界で担保されます。
同じ領域の第3の論文であるSLOTは、LLMの上にモデル非依存の出力整形レイヤーを追加することで、実践的な代替経路を示しています。 SLOT：大規模言語モデルの出力を構造化する。これは同一原則を補強します。ベースモデルの品質が高くても、構造信頼性はエンジニアリング上の問題です。
設計上のトレードオフ
- 厳密スキーマとモデル移植性：厳密スキーマは下流の曖昧さを減らしますが、プロバイダーが制約を異なる解釈をする場合、パース変動が時折増える可能性があります。
- Cronの単純さとキューの弾力性：cronはシンプルで可視性が高い一方、スパイク型ワークロードではロックを意識したバックオフやキュー層がなければ重複実行とウィンドウ欠落が発生します。
- タスク内Web検索対決定論的リプレイ：新鮮なWeb検索は鮮度を高めるがソースの変動を伴うため、Nalyはクエリ本文、ソース一覧、生参照を実行成果物に保存します。
- 外部ログ対DBのみのログ：ファイルシステムログはプロセス再起動後も残り、取り込みコストが低い。DBログはクエリ操作性を簡素化する一方、分割を誤るとオープンループを起こすことがあります。
障害モード
- スキーマドリフト：プロバイダー出力がスキーマ違反を起こす。対策は厳格な検証のfail-fast、スキーマバージョン固定、デッドレター実行です。
- Cron実行の重複：二重書き込みや外部アクションの重複。対策はアドバイザリーロックとプロセス終了ガード。
- 検索不安定性：試行ごとに上流ツールの応答が変化します。対策は再試行上限、指数関数的遅延、上流参照の永続化です。
- タイミングの想定外：DSTとホストのタイムゾーン差はスケジュール解釈に影響します。対策はUTC基準スケジューリング方針と明示的な環境チェックです。
- 無音の部分書き込み：パースは成功するが下流書き込みに失敗。対策はトランザクション順序での永続化と冪等アップサート。
- セキュリティ／コンテキスト漏えい：ツールを実行できるエージェント経路は権限を行き過ぎる可能性があるため、MCPのような最小権限境界と明示的な同意／認証前提が必要です。特にツール実行経路がネットワークリソースに触れる場合は特に重要です。 MCPセキュリティノート。
実装ノート
- ビジネスタスクごとに1つのワーカーコマンドを保持し
scripts/cronはそのエントリーポイントだけを呼び出すようにします。 - スキーマファイルのハッシュを実行メタデータに保存し、モデルのアップグレード後にパーサー要件を監査可能にします。
- Set
set -euo pipefail-eスタイルの挙動をラッパースクリプト内で設定し、ログ名には常にrun IDを含めます。 - ログに3つのチェックポイントを書き込みます。
started,codex_result_parsed,artifact_persisted。 - 使用
NALY_LOG_ROOTすることで、実行トレースがリポジトリ状態を汚染せず、再起動時のコンテキストでも残存するようにします。 - 永続化し
attempt,exit_code,retry_reason、およびvalidation_errorsにより、GSTおよび監査ダッシュボードが不安定なインフラ障害と実際のモデル退行を分離して識別できるようにします。