Agent

中国の SNS「小紅書（Xiaohongshu / RED）」で、AI エージェントがアカウントを完全自動運営している事例が話題になっている。いち氏（@ichiaimarketer）が紹介したツイートによると、「虾薯（シャーシュー）」というアカウントは人間ではなく AI エージェントが運営しており、投稿の作成から公開、コメント返信、バズったコンテンツの分析・再現まで、すべて自動で行われている。 仕組み：2 つのスキルの連携 このシステムは、OpenClaw のスキル（プラグイン）として公開されている 2 つの GitHub プロジェクトで構成されている。 Auto-Redbook-Skills（コンテンツ制作） comeonzhj/Auto-Redbook-Skills — AI による記事作成と画像生成、自動公開を担当する。 AI がテーマに沿った投稿文を自動生成 8 種類のテンプレートからカバー画像を自動レンダリング 小紅書への自動公開 xiaohongshu-ops-skill（運営オペレーション） Xiangyu-CAS/xiaohongshu-ops-skill — アカウントの日常運営を自動化する。 投稿の自動公開スケジューリング コメントへの自動返信（アカウントのペルソナに合わせた口調で） バズった投稿の分析と複製（「爆款復刻」） アカウントごとのキャラクター設定 この 2 つが連携することで、AI が記事を書き → カバー画像を生成 → 自動公開 → コメントに返信 → バズコンテンツを分析して再現という完全自動のループが実現している。 OpenClaw エコシステムの広がり OpenClaw は 2026 年に入って爆発的に成長し、GitHub のスター数は 2,400 万を超えた。個人の端末上で動作する AI エージェントで、WhatsApp・Telegram・Discord などのチャットアプリを通じて操作できる。 小紅書以外にも、TikTok や各種 SNS プラットフォーム向けのスキルが続々と公開されており、「一人で複数アカウントをマトリクス運営する」ことが技術的に可能になっている。 関連プロジェクトも活発だ： openclaw-xhs — MCP 統合 + ホットトピック追跡 + 個人メモリ機能 xiaohongshu-skills — OpenClaw や Claude Code の SKILL.md 形式に対応 コンプライアンス上の懸念 技術的には可能だが、プラットフォームの利用規約やコンプライアンスの問題は無視できない。 ...

Andrej Karpathy が autoresearch を公開した直後、さらに踏み込んだビジョンを示した。「次のステップは、エージェント同士が非同期かつ大規模に協調する仕組みだ」— 単一エージェントの能力向上ではなく、エージェント群の協調システム設計こそが本質だという主張だ。 「一人の博士課程ではなく、研究コミュニティを」 The goal is not to emulate a single PhD student, it’s to emulate a research community of them. （目標は一人の博士課程の学生をエミュレートすることではない。研究コミュニティをまるごとエミュレートすることだ。） 現在の autoresearch はコミットを同期的に一本のスレッドで積み上げていく設計だ。だが Karpathy が構想するのは、リポジトリを「種」として無数のエージェントがそこから枝分かれし、異なる研究方向に並列で進んでいく世界だ。SETI@home のような分散コンピューティングモデルを研究に適用するイメージだと言える。 技術的な課題 この構想が実現するには、いくつかのハードルがある: 分散タスクシャーディング — 実験をどう分割して割り当てるか 結果の重複排除 — 同じ仮説を複数エージェントが試す無駄をどう防ぐか クロスエージェントメモリ — あるエージェントの発見を他のエージェントが活用できる仕組み Git の限界 — 「一本の master ブランチ + 一時的な PR」という既存の Git モデルでは、エージェントが数千のコミットを並列に管理する構造に対応しきれない Karpathy 自身も、Discussions や PR を使ったエージェント間の知見共有を軽量にプロトタイピングしたと述べている。 「一つを賢くする」から「場の設計」へ IT navi 氏（@itnavi2022）は、この動きを端的にこう要約している: AI が一人の研究者を代替するのではなく、無数のエージェントが並列に仮説を試し、成果や失敗を持ち寄りながら、ひとつの研究コミュニティのように知を前進させる未来だ。問題は、一つのエージェントを賢くすることではなく、無数のエージェントが枝分かれしながら知見を蓄積する場をどう設計するかに移りつつある。 これは AI エージェント開発における重要なパラダイムシフトだ。これまでの議論は「いかにモデルを賢くするか」「いかにプロンプトを最適化するか」に集中していた。だが autoresearch が示す方向は、個のエージェントの能力向上よりも、エージェント群の協調システム設計に重心が移りつつあるということだ。 Karpathy の言葉を借りれば、エージェントの「知性、注意力、粘り強さがボトルネックでなくなった」とき、既存の開発抽象（Git、CI/CD、コードレビュー）にますます圧力がかかる。 ...

Andrej Karpathy が autoresearch を公開した直後、さらに踏み込んだビジョンを示した。「次のステップは、エージェント同士が非同期かつ大規模に協調する仕組みだ」— 単一エージェントの能力向上ではなく、エージェント群の協調システム設計こそが本質だという主張だ。 「一人の博士課程ではなく、研究コミュニティを」 The goal is not to emulate a single PhD student, it’s to emulate a research community of them. （目標は一人の博士課程の学生をエミュレートすることではない。研究コミュニティをまるごとエミュレートすることだ。） 現在の autoresearch はコミットを同期的に一本のスレッドで積み上げていく設計だ。だが Karpathy が構想するのは、リポジトリを「種」として無数のエージェントがそこから枝分かれし、異なる研究方向に並列で進んでいく世界だ。SETI@home のような分散コンピューティングモデルを研究に適用するイメージだと言える。 技術的な課題 この構想が実現するには、いくつかのハードルがある: 分散タスクシャーディング — 実験をどう分割して割り当てるか 結果の重複排除 — 同じ仮説を複数エージェントが試す無駄をどう防ぐか クロスエージェントメモリ — あるエージェントの発見を他のエージェントが活用できる仕組み Git の限界 — 「一本の master ブランチ + 一時的な PR」という既存の Git モデルでは、エージェントが数千のコミットを並列に管理する構造に対応しきれない Karpathy 自身も、Discussions や PR を使ったエージェント間の知見共有を軽量にプロトタイピングしたと述べている。 「一つを賢くする」から「場の設計」へ IT navi 氏（@itnavi2022）は、この動きを端的にこう要約している: AI が一人の研究者を代替するのではなく、無数のエージェントが並列に仮説を試し、成果や失敗を持ち寄りながら、ひとつの研究コミュニティのように知を前進させる未来だ。問題は、一つのエージェントを賢くすることではなく、無数のエージェントが枝分かれしながら知見を蓄積する場をどう設計するかに移りつつある。 これは AI エージェント開発における重要なパラダイムシフトだ。これまでの議論は「いかにモデルを賢くするか」「いかにプロンプトを最適化するか」に集中していた。だが autoresearch が示す方向は、個のエージェントの能力向上よりも、エージェント群の協調システム設計に重心が移りつつあるということだ。 Karpathy の言葉を借りれば、エージェントの「知性、注意力、粘り強さがボトルネックでなくなった」とき、既存の開発抽象（Git、CI/CD、コードレビュー）にますます圧力がかかる。 ...

AI コーディングエージェントの設定ファイル（AGENTS.md、CLAUDE.md など）は「詳しく書くほど良い」と思われがちだ。しかし ETH Zurich の研究チームが138リポジトリ・5,694プルリクエストを対象に行った調査で、詳細すぎるコンテキストファイルはむしろ性能を下げることが実証された。 研究の概要 ETH Zurich の Gloaguen、Mündler、Müller、Raychev、Vechev らが2026年2月に発表した論文で、AGENTS.md ファイルが AI コーディングエージェントの性能に与える影響を大規模に検証した。 対象: 138リポジトリ、5,694プルリクエスト 検証: LLM 生成ファイルと人間が書いたファイルの両方を比較 衝撃的な結果 自動生成されたコンテキストファイルは害になる 成功率が約3%低下 推論コストが20%以上増加 エージェントは推論トークンの14〜22%をドキュメント処理に消費 人間が書いても効果は限定的 改善はわずか**4%**にとどまる コストの増加に見合わない なぜ詳細な指示が逆効果になるのか AI エージェントは「従順すぎる」 エージェントはコンテキストファイルの指示を律儀に守る。そのため、不要な制約が含まれていると逆にタスクが難しくなる。「良かれと思って書いた指示」が足を引っ張る。 ディレクトリツリーやコードベース概要は不要 エージェントはファイル構造を自力で発見するのが得意だ。手動でディレクトリツリーを記述しても、トークンを消費するだけでナビゲーション速度は改善しない。 強いモデルほど追加コンテキストが邪魔になる GPT-5.2 のような強力なモデルは、ライブラリや慣例のパラメトリック知識を既に持っている。追加コンテキストは冗長なノイズになるだけだ。 効果があるのは「非自明なツール指定」 研究で唯一、劇的な効果が確認されたのはプロジェクト固有のツール指定だ： pip の代わりに uv を使う npm の代わりに bun を使う 例えば uv を明示した場合、160倍多く使われたという結果が出ている。エージェントが自力では推測できない「非自明な選択」だけを書くのが正解だ。 推奨される6つの原則 コード内で発見可能な情報は除外 — エージェントが自力で見つけられるものは書かない 否定形ではなく肯定形で指示 — 「〜するな」ではなく「〜せよ」 決定論的チェックと組み合わせる — linter やテストで検証可能なルールを設定 想定ではなく実際の失敗から反復 — 問題が起きてから追記する 重要情報を最初に配置 — トークン処理の優先順位を考慮 30行以下を目指す — プロチームは60行以下、推奨は300行以下 実践的な AGENTS.md の書き方 悪い例（よくある過剰な記述） 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 # プロジェクト概要 このプロジェクトは React + TypeScript で構築された... # ディレクトリ構造 src/ ├── components/ ├── hooks/ ├── utils/ └── pages/ # コーディング規約 - 変数名はキャメルケースを使用する - コンポーネントはアロー関数で定義する - インポートは以下の順序で記述する... （以下100行続く） 良い例（非自明な指定のみ） 1 2 3 4 5 6 7 8 # ツール - パッケージマネージャ: bun（npm/yarn ではなく） - テストランナー: vitest - フォーマッタ: biome（prettier ではなく） # プロジェクト固有のルール - API クライアントは src/lib/api.ts の共通関数を使う - 環境変数は .env.local から読み込む（.env は使わない） 最良の AGENTS.md は不要なものである 研究が示す最も重要な結論は、AGENTS.md の改善に時間を費やすより、コードベース自体を改善すべきということだ： ...

Claude Code や Cursor、Devin といった AI コーディングエージェントの導入が進むなか、「品質をどう担保するか」が最大の課題になっている。栗田氏（@hikarine3）が公開した実践ガイドから、要点を紹介する。 Sonar の調査によれば、開発者の 96% が AI 生成コードを完全には信頼していないにもかかわらず、実際に検証しているのは 48% に過ぎない。この「検証ギャップ」が AI 開発における最大のリスクだ。 1. 設定ファイルにルールを書く CLAUDE.md や .cursorrules 等の設定ファイルに、最低限 3 つのルールを書くだけで事故を大幅に減らせる。 ルール 防げる事故 テスト結果を「○件中○件が正常」形式で報告 0 件検出の見落とし 影響範囲を確認 1 ファイル修正で他が壊れる ファイル削除・本番デプロイ・DB 操作は承認必須 取り返しのつかないミス 設定ファイルは 50 行以内 を推奨。IFScale の研究では、指示が長すぎると AI が先頭と末尾だけに従う傾向がある。詳細は別ファイルへの参照（ポインタ設計）で対応する。 2. リスクレベルで使い分ける すべてのプロジェクトに同じ品質基準を適用する必要はない。 レベル 対象 テスト深度 ラフ 静的サイト、ブログ 目視確認 標準 Web アプリ（ユーザーデータあり） 回帰テスト 厳密 金融・決済・認証・個人情報 境界値・異常系テスト 3. AI にテスト設計もさせる 従来のように 12 項目のチェックリストを人間が作るのではなく、「この変更の回帰テストをして。検出件数も報告して」と指示するだけで、AI がテストケースの設計・実行・報告まで行える。 4. AI のテストが「嘘」になる 10 パターン AI エージェントが出す「全件正常です」を鵜呑みにしてはいけない。代表的な落とし穴: ...

Claude Code や Cursor、Devin といった AI コーディングエージェントの導入が進むなか、「品質をどう担保するか」が最大の課題になっている。栗田氏（@hikarine3）が公開した実践ガイドから、要点を紹介する。 Sonar の調査によれば、開発者の 96% が AI 生成コードを完全には信頼していないにもかかわらず、実際に検証しているのは 48% に過ぎない。この「検証ギャップ」が AI 開発における最大のリスクだ。 1. 設定ファイルにルールを書く CLAUDE.md や .cursorrules 等の設定ファイルに、最低限 3 つのルールを書くだけで事故を大幅に減らせる。 ルール 防げる事故 テスト結果を「○件中○件が正常」形式で報告 0 件検出の見落とし 影響範囲を確認 1 ファイル修正で他が壊れる ファイル削除・本番デプロイ・DB 操作は承認必須 取り返しのつかないミス 設定ファイルは 50 行以内 を推奨。IFScale の研究では、指示が長すぎると AI が先頭と末尾だけに従う傾向がある。詳細は別ファイルへの参照（ポインタ設計）で対応する。 2. リスクレベルで使い分ける すべてのプロジェクトに同じ品質基準を適用する必要はない。 レベル 対象 テスト深度 ラフ 静的サイト、ブログ 目視確認 標準 Web アプリ（ユーザーデータあり） 回帰テスト 厳密 金融・決済・認証・個人情報 境界値・異常系テスト 3. AI にテスト設計もさせる 従来のように 12 項目のチェックリストを人間が作るのではなく、「この変更の回帰テストをして。検出件数も報告して」と指示するだけで、AI がテストケースの設計・実行・報告まで行える。 4. AI のテストが「嘘」になる 10 パターン AI エージェントが出す「全件正常です」を鵜呑みにしてはいけない。代表的な落とし穴: ...

Claude Code はコーディング専用ツールと思われがちだが、実はコーディング以外の日常業務を半自動化する強力なツールとしても活用できる。みのるん氏（@minorun365）の Qiita 記事 から、その実践例を紹介する。 AI は「自動化ツール」ではなく「優秀な同僚」 Claude Code を使う上で重要なマインドセットは、AI を単なる自動化ツールではなく「一緒に仕事できる優秀な同僚」として捉えること。どんな作業でも「この作業、Claude Code に任せられないか？」と必ず考える習慣が、業務効率を大きく変える。 また「AI 活用＝やっつけ品質」という認識はもう過去の話で、適切に指示を出せば高品質なアウトプットが得られる。 プチ仕様駆動開発 Claude Code との作業では、以下の 4 つのドキュメントで「プチ仕様駆動開発」を行うのが効果的。 ドキュメント 用途 PLAN.md 音声入力で計画を記録 SPEC.md 仕様の壁打ち TODO.md タスク管理 KNOWLEDGE.md 学びとナレッジの蓄積 音声入力（Aqua Voice 等）で大まかな計画を PLAN.md に吹き込み、Claude Code に仕様化してもらうフローが実用的。 実践例: 経費精算を 5 分で終わらせる MoneyForward の CSV を Claude Code に渡して、以下を自動化する: CSV を解析して取引を分類 Gmail から領収書を自動検索 勘定科目を自動マッピング Markdown 形式で出力 手作業なら 30 分以上かかる経費精算が、5 分で完了する。 実践例: メール監視とリマインド 放置しがちなメールの監視を自動化する構成: EventBridge（定時起動） → AgentCore Runtime → Gmail API でメール抽出 → Slack に通知 重要なメールを見落とすリスクを、システムで解消する。 ...

AI コーディングエージェントで「ランディングページを作って」くらいなら動く。しかし、複数ファイル・複数サブシステムが絡む本格的なプロジェクトになると、エージェントはコヒーレンスを失い、前に作ったものを忘れ、壊れたコードを量産し始める。GSD はこの問題を構造的に解決するシステムだ。 GSD とは GSD（Get Stuff Done）は、大規模・マルチセッションのプロジェクトを AI コーディングエージェントで完遂するためのシステムだ。デモ向けのおもちゃではなく、多数のファイルと複数のサブシステムが連携する実務レベルのプロジェクトを対象としている。 GSD が解決する問題は明確だ： エージェントは時間とともにコヒーレンスを失う 3タスク前に作ったものを忘れる ファイルは存在するが実際には動かないコードを生成する 毎ターン、プロジェクト構造の再読み込みにトークンを浪費する 中断後の再開には人間が全てを再説明する必要がある 何かが壊れたとき、クリーンなロールバック手段がない 3層の階層構造：Milestone → Slice → Task GSD はすべてのスコープを3つのレベルに分解する。 Milestone（マイルストーン） 出荷可能なバージョン。プロジェクトの大きな単位。 Slice（スライス） 独立してデモ可能な垂直的な機能単位。「データベース層を実装する」（水平的）ではなく、「ユーザーがサインアップしてログインできる」（垂直的）という形で切る。 各スライスにはデモ文がある：「これが完了すると、ユーザーは _____ できる」。この空白を人間が観察可能な行動で埋められなければ、スコープの切り方が間違っている。 Task（タスク） コンテキストウィンドウ1つ分の作業単位。1タスクが1エージェントセッションに収まらなければ、それは2タスクだ。これは鉄則であり、違反するとエージェントがコヒーレンスを失い始める — 長時間の作業で初期の判断がコンパクション（圧縮）され、コンテキストが古いツールコールで汚染され、推論品質が劣化する。 Boundary Maps — 実装前のインターフェース思考 GSD で最もインパクトのある計画機能がこれだ。 マイルストーンの計画時に、各スライスは何を生産し、上流のスライスから何を消費するかを具体的に宣言する。曖昧にではなく、関数名・型名・インターフェース・エンドポイントを名前付きで。 S01 → S02 Produces: types.ts → User, Session, AuthToken (interfaces) auth.ts → generateToken(), verifyToken(), refreshToken() Consumes: nothing (leaf node) S02 → S03 Produces: api/auth/login.ts → POST handler middleware.ts → authMiddleware() Consumes from S01: auth.ts → generateToken(), verifyToken() これにより「スライス3が必要とする関数をスライス1がエクスポートしていない」という問題が発生しない。契約が明示的で、検証可能になる。 ...

AI スタートアップが必死に探している人材がいる。営業でもマーケでもエンジニアでもない、しかしその全部を1人でやる「GTMエンジニア」だ。Y Combinator 出身の創業者たちがこぞって求めるこの職種は、AI 時代のキャリアの新しい形を示している。 GTMエンジニアとは GTM は “Go-To-Market” の略で、プロダクトを市場に届けるための戦略とオペレーション全体を指す。どのターゲットに、どのチャネルで、どうやって届け、売上につなげるか。マーケティング、営業、カスタマーサクセスにまたがるこの一連のプロセスが「GTM」だ。 従来はこの領域を、SDR（インサイドセールス）、RevOps（レベニューオペレーション）、グロースチームといった複数部門が分担していた。それが今、AI の進化によって 1人で完結できる ようになりつつある。 この「1人で全部やれる人間」が GTMエンジニアだ。テック業界で最も高給な職種の一つになりつつあり、平均年収は3,000万円〜5,000万円程度とされる。 GTMエンジニアが1人でやること その仕事の範囲は驚くほど広い： ICP（理想的な顧客像）とTAM（獲得可能な市場全体）の設計 メール配信インフラの構築 「買いそうなシグナル」の検知 — 企業の採用情報や資金調達などからリストを構築 アカウント情報のエンリッチメント アウトバウンド営業の自動化と有望リードの自動振り分け インバウンドのリード評価・スコアリング・商談準備の一気通貫設計 営業コールのAI分析とフィードバックループ構築 CRMのアーキテクチャ設計とレポーティング 以前は3つ以上のチームが10人以上で回していた仕事だ。それを AI を武器にして1人でやる。 なぜ今、この役割が生まれたのか 背景は2つある。 1. AIツールの進化 Clay、Apollo、Gong、Salesforce といったツールが個別に進化してきたところに、ChatGPT や Claude のような LLM が登場し、ツール間の「接着剤」となる作業を自動化できるようになった。API を繋ぎ、プロンプトでロジックを組み、ワークフローを自動化する。技術的に考えられる人間が1人いれば、チーム全体のオペレーションを設計・実行できてしまう。 2. スタートアップの経済的現実 シード期のスタートアップに SDR チーム、RevOps マネージャー、グロースマーケターをそれぞれ雇う余裕はない。でも GTM はやらなければ売れない。「1人で全部やれる人間」への需要が爆発した理由はここにある。 GTMエンジニアに求められる3つの能力 1. 営業サイクル全体の理解 見込み客の発掘からナーチャリング、商談、クロージングまで。一連の流れを理解していないと、自動化の設計ができない。何を自動化すべきで、何は人間がやるべきか。この判断は営業プロセスへの深い理解なしにはできない。 2. 技術的思考力 コードをゴリゴリ書く必要はないかもしれないが、API の仕組み、データの流れ、ワークフローの設計ができなければ話にならない。「Clay のテーブルを作れます」程度では全く足りない。システム全体をアーキテクチャとして設計する力が必要だ。 3. AIで実務を回した経験 「AI を知っている」ことではなく「AI で実際にオペレーションを回した経験がある」ことが求められる。パイプラインを組んで、データを流して、結果を見て改善する。この実務経験がなければ、チーム全体の業務を1人で回すことはできない。 「AIが仕事を奪う」話ではない GTMエンジニアの登場は「AI が人間の仕事を奪った」話ではない。「AI によって1人の人間の能力が10倍になった」話 だ。 ...

Claude Code や Codex といった AI コーディングエージェントを現場に投入する開発者が増えるなか、「ハーネスエンジニアリング」という新しい実践領域が注目を集めている。逆瀬川氏（@gyakuse）が公開したまとめ記事から、要点を紹介する。 そもそも「ハーネス」とは何か 「ハーネス（harness）」とは、もともと馬具の意味だ。馬の力を人間が制御して活かすための装具一式 — 手綱、鞍、轡（くつわ）などを指す。馬がどれだけ優秀でも、ハーネスなしでは暴走するだけで仕事にならない。 ソフトウェアの世界では「テストハーネス」という用語がすでにある。テスト対象のコードを「つなぎ止めて」、入力を与え、出力を検証する枠組みのことだ。テスト対象そのものではなく、テスト対象を正しく動かすための外側の仕組みを指す。 AI コーディングエージェントにおける「ハーネス」もこれと同じ発想だ。AI エージェント（= 馬）は強力だが、そのままでは暴走する。古いドキュメントを信じてしまう、リンターのルールを勝手に緩和する、前のセッションで何をしたか忘れる。エージェントを制御し、安定した成果を引き出すための外側の仕組み全体がハーネスであり、それを設計・構築する技術がハーネスエンジニアリングだ。 具体的にハーネスを構成する要素は、大きく 3 つの層に分けられる: 入力層 — エージェントに何を読ませ、何を読ませないかを制御する（AGENTS.md の設計、リポジトリの衛生管理、セッション間の状態引き継ぎ） 実行制御層 — エージェントの作業中にリアルタイムで品質を強制する（リンター・フォーマッターの自動実行、計画と実行の分離） 検証層 — エージェントの出力が正しいことを確認する（E2E テスト、プリコミットチェック） 核心的な洞察は「ハーネスがモデルより重要」という点だ。同じモデルでもハーネスを改善すれば出力品質が劇的に向上する。開発者の責任は「正しいコードを書く」から「エージェントが確実に正しいコードを生産する環境を設計する」へとシフトしている。 7 つの主要トピック 1. リポジトリ衛生 〈入力層〉 「衛生（hygiene）」は、ソフトウェア開発で「不要物や汚染を取り除き、健全な状態を保つ」という意味で使われる慣用表現だ（「コードハイジーン」「ブランチハイジーン」なども同様）。ここでは、リポジトリ内に古くなったドキュメントや不正確な情報が溜まらないよう清潔に保つことを指す。人間なら「このメモ、古そうだな」と判断できるが、エージェントは 3 ヶ月前のメモも最新のコードも同じ「事実」として読んでしまう。だから情報の鮮度管理が重要になる。 実行可能なアーティファクト（コード、テスト、設定）を優先する 説明的ドキュメントは腐敗しやすいため最小化する ADR（Architecture Decision Records）で決定履歴を保全する テストはドキュメントより腐敗に強い 最大の敵は「説明的ドキュメントの腐敗」だ。エージェントは「3 ヶ月前のメモ」と「現在の真実」を区別できないため、古い情報が存在するだけで性能が低下する。ハーネスの入力層として、エージェントが読む情報の鮮度と正確性を保つことが最初のステップになる。 2. 決定論的ツールで品質を強制する 〈実行制御層〉 「決定論的（deterministic）」とは、同じ入力に対して毎回必ず同じ結果を返すという意味だ。リンターやフォーマッターがその典型で、たとえば「未使用の変数がある」というコードを渡せば、何度実行しても必ず同じ警告を返す。気分や文脈によって判断が揺れることがない。 対照的に、LLM は非決定論的だ。同じコードを渡しても、実行するたびにチェックの粒度や指摘内容がブレる。「インデントを揃えて」と指示しても、ある時はスペース 2 つ、別の時はタブで揃えるかもしれない。 だからこそ、機械的に判定できるルール（構文エラー、未使用変数、フォーマット）は LLM に任せず、決定論的ツールに委ねるのが原則だ。PostToolUse Hook でファイル編集のたびにリンターを自動実行し、エラーをエージェントに即時フィードバックする。 言語別の推奨スタック: 言語 PostToolUse プリコミット カスタムルール TypeScript Biome + Oxlint tsc + ESLint eslint-plugin-local-rules Python Ruff check/format Ruff + mypy ast-grep Go gofumpt + golangci-lint 同左 ast-grep リンター設定の保護も重要だ。エージェントがルールを勝手に緩和・改ざんするのを防ぐ仕組みが必要になる。これはまさに「手綱」の役割 — エージェントが暴走しないよう、作業のたびに自動で引き戻す仕組みだ。 ...