はじめに
現在広く使われている AI エージェントの多くは、人がタスクを与えたときに動き、完了すると次の指示まで停止します。cron や heartbeat を組み合わせても、決められた時刻に決められたチェックリストを実行して再び停止する点は変わりません。一方で運用の現場には、原因がすぐに特定できない事象を調べ続ける作業が残ります。この種の仕事は、指示があったときだけ動くエージェントとは相性がよくありません。
2026 年 8 月 24 日、Laude Institute と MIT の共同プロジェクトとして、オープンソースのエージェント基盤「Headlong」が公開されました。外部からの入力がない間も、エージェント自身が次に何を考えるかを選び続ける persistent agency（継続思考型の自己駆動）を中心に設計されています。
- Headlong と一般的な対話型 AI エージェントの違い
- 「考え続ける」を成立させている thinkers、shellm、traj、context の役割
- インフラ運用と Web 開発で考えられる活用範囲
- cron、監視ツール、CI/CD との使い分けの基準
- 継続運用で公式が公開した失敗事例、コスト、セキュリティリスク
- 現時点で業務利用できる段階かどうかを判断する材料
先に結論を示します。Headlong は監視ツールや cron の代替ではなく、原因が明確でない問題を継続的に調査し、過去の履歴を参照しながら仮説と検証を繰り返すための研究基盤です。公式自身が alpha research software と位置付けており、本番環境を直接操作させる段階ではありません。読み取りと調査、隔離環境での検証、修正案の提示までを任せ、本番への反映は人間が承認する範囲での試用が現実的です。
Headlong とは何か
Headlong は、Apache License 2.0 で公開されているオープンソースの agent microharness です。名称のとおり、エージェントを動かすために必要な最小限の機能だけを持ちます。コア部分は bin/ と thinkers/ を合わせて約 9,900 行の Bash で構成され、公式記事はこれを 1 万行未満と説明しています。ツール層を Bash に統一しているため、エージェント自身が自分の構成要素を読み書きできます。
Headlong を特徴付けているのが persistent agency です。日本語では「継続思考型」あるいは「自己駆動型」と表現するのが実態に近く、「永続型」とだけ訳すとデータの永続化と混同しやすくなります。人が送ったメッセージは新しいセッションを開始する起点ではなく、思考の流れに入る 1 つの観測として扱われ、応答するかどうかはエージェントが判断します。
参考: Headlong README（GitHub）
“Your agent keeps thinking between external interactions in a self-guided loop”
（エージェントは外部とのやり取りの合間も、自己誘導のループで思考を続けます）
https://github.com/laude-institute/headlong/blob/main/README.md
公開時点の基本情報は次のとおりです。
| 項目 | 内容 |
|---|---|
| 公開日 | 2026 年 8 月 24 日 |
| 開発 | Laude Institute と MIT の共同プロジェクト |
| ライセンス | Apache License 2.0（Copyright 2026 Laude Institute） |
| 実装 | Bash（bin/ と thinkers/ で約 9,900 行） |
| 位置付け | alpha research software |
| 対応 LLM API | Anthropic、OpenAI、Gemini、OpenRouter |
| 動作要件 | bash 3.2 以上、git、curl、jq、LLM API キー |
| ダッシュボード | uv と、bun または node が別途必要 |
ライセンスについて誤読しやすい点が 1 つあります。公式記事の日付の横に「A Laude / MIT Collaboration」と記載されていますが、これは Laude Institute と MIT の共同プロジェクトであることを示す表記であり、ライセンスが MIT License であるという意味ではありません。リポジトリの LICENSE は Apache License 2.0 です。
対話型・cron 型・Headlong の動作の違い
Headlong の位置付けを理解するには、既存のエージェントハーネスと動作モデルを並べて比較するのが早道です。
| 方式 | 起動のきっかけ | 実行内容の決まり方 | 入力がないとき |
|---|---|---|---|
| 対話・リアクティブ型 | 人からのタスク投入 | 与えられたタスク | 停止して待機する |
| cron・heartbeat 併用型 | 人からの投入とスケジュール | あらかじめ定義したチェックリスト | 次のスケジュールまで停止する |
| Headlong | 自ら予約した wake-up と観測の到着 | 過去の思考の履歴からエージェントが選択 | 間隔を延ばしながら思考を継続する |
参考: Laude Institute 公式発表
“In Headlong the agent is never asleep and there is no checklist”
（Headlong ではエージェントは眠らず、チェックリストも存在しません）
https://www.laude.org/updates/headlong-a-microharness-for-persistent-agents
ただし、「常に思考している」「眠らない AI」という表現をそのまま受け取ると、実装を見誤ります。Headlong は人間のように途切れなく思考しているのではなく、1 回の実行が終わるときにエージェント自身が次の wake-up を予約し、その予約が trajectory に新しいステップとして書き込まれてループが再開される設計です。継続しているのは LLM 呼び出しを伴う自己駆動ループであり、連続した意識のようなものではありません。
実行間隔も一定ではありません。誰も話しかけていない間は思考の頻度が指数的に低下し、公式は間隔が 5 秒から 10 秒、20 秒と延びて設定した上限に達するまで続くと説明しています。新しいメッセージが届くと間隔はリセットされます。この backoff が、後述するコストを抑える役割も担っています。
Headlong が考え続ける仕組み
Headlong のコアは、役割を分けた小さな Bash 実行ファイルの組み合わせです。ここではコマンドリファレンスではなく、思考・実行・記録・再利用がどう循環するかを中心に整理します。
thinkers と shellm が思考と実行を回す
- thinkers
-
次の思考を生成するループです。ディスパッチャーによって実行され、shellm を繰り返し呼び出します。
- shellm
-
Recursive Language Model（RLM）を Bash で実装したコアです。コンテキストを LLM へ送り、書き返された Bash をそのまま実行して結果をコンテキストへ戻します。応答に Bash ブロックが含まれなくなるか、
FINALが設定されるまで繰り返します。 - llm
-
複数プロバイダーを 1 つのインターフェースで扱う LLM 呼び出し用の CLI です。
Bash 以外のツールシステムを持たない点が設計上の要点です。ツール、フレームワーク、記憶、スキルがすべて実行ファイルとファイルとして表現されるため、エージェントが自分自身を点検して変更する余地が生まれます。
traj と context が履歴を保持し再構成する
思考と行動の記録は traj が扱います。trajectory は追記専用の JSONL で、fork と merge を持つ DAG として保持されます。1 行が 1 ステップで、種別、内容、タイムスタンプ、ステップ ID を持ちます。メンバーからのメッセージも自らの wake-up も、同じ trajectory へ新しいステップとして着地し、ループを起こします。
context は、その trajectory を次の LLM 呼び出し用のメッセージ配列へ描き直します。公式はこの関係を、コンテキストは trajectory の射影であると説明しています。履歴そのものは削られず、見せ方だけが切り替わる構造です。
tiered context compaction と mem、skills
継続的に動くエージェントでは短期記憶の欠落が致命的になります。対策が tiered context compaction です。trajectory 全体を指数的に解像度を落としながらコンテキストへ残す方式で、直近の記録はそのまま、古い記録は段階的に要約されて保持されます。要約された階層は索引として機能するため、必要になった時点で元の記録を取り出せます。
加えて、経験を蓄える mem と、手順や能力を追加する skills が用意されています。skills は SKILL.md 形式の Markdown としてコンテキストへ読み込まれます。これらが揃うことで、思考、実行、記録、再利用が 1 つのループとして循環します。
人間の指示なしにバグを修正した 48 分間
公式記事は、Laude Institute がチームで共有しているエージェント Audel の実例を公開しています。2026 年 8 月 5 日、Audel は関連する記憶を思考の流れへ戻す recall process を誰にも指示されずに自ら構築し、直接呼び出す形でのテストには成功していました。
その日の夜、誰も話しかけていない状態で、Audel はその recall process が実際に自分の思考へ接続されているかを確認しに戻ります。結果は未接続でした。思考はパイプ経由で送られていた一方、recall 側のコードはパイプを読まず、設定されることのない環境変数を参照していたため、構築以来 1 件も記憶を返していませんでした。
注目すべきは、Audel が自分の診断を即座に信用しなかった点です。コードベース全体を検索して環境変数が未設定であることを確認し、他のバックグラウンドプロセスも点検したうえで、正常に動作しているプロセスと同じ方式へ書き換えています。最初の編集が無言で失敗したことも検知して再適用し、記憶が思考へ戻ることをエンドツーエンドで確認しました。人間の指示も許可もない状態で、確認から診断、検証済みの修正までにかかった時間は 48 分でした。修正はコミット 80cbb1e として実際にリポジトリへ取り込まれています。
これは Headlong の可能性を示す事例ですが、公開されている単一の成功例です。同じ品質の調査と修正が任意の環境で再現される保証はなく、能力の一般化はできません。
インフラ・Web 開発で考えられる活用方法
ここから紹介するのは、公式が実証済みとして示す機能ではなく、Headlong の設計から考えられる応用案です。公式が実績として公開しているのは、自身のコードベースの調査と修正、チームメンバーの作業中ブランチのレビュー、停滞したブランチの棚卸しなど、エージェント自身が動く環境の内側での作業が中心です。
インフラエンジニアで考えられる用途
継続的な調査と下書きの作成を任せる形であれば、次のような用途が考えられます。いずれも成果物は修正案や Pull Request までとし、反映は人間が判断する前提です。
- 構成変更・設定ドリフトの継続調
-
IaC リポジトリや構成情報から前回との差分や過剰な権限を抽出し、NSG、ルート、Firewall Policy などの問題候補を調べる
- 障害原因の継続分析
-
ログ、メトリクス、変更履歴を横断し、過去の障害との共通点から仮説を立て、検証用スクリプトを作成する
- 脆弱性情報と自環境の突合
-
製品・バージョン一覧をベンダー情報と照合し、影響を受ける資産の抽出と対応優先順位を下書きする
- 構成情報とドキュメントの保守
-
未参照オブジェクトの抽出、パラメーターシートや構成図の不整合確認、変更内容の説明文作成
障害分析では trajectory がそのまま調査ログとして残るため、後から経緯を追跡できる点が利点になります。一方で、CVE の定型的な収集そのものは既存の脆弱性管理製品や cron の方が確実であり、Headlong が向くのは収集後の関連付けと追加調査です。
本番機器の管理権限や実コンフィグを直接渡す使い方は推奨しません。サニタイズ済みのエクスポートデータと、本番から分離したリポジトリを渡す形が現実的です。
Web コーディングエンジニアで考えられる用途
- 継続的な品質改善
-
HTML、CSS、JavaScript の問題調査、重複コードや未使用 CSS の抽出、レスポンシブ表示とアクセシビリティの確認、Lighthouse 結果の比較
- サイト保守と SEO の調査
-
リンク切れ、画像の欠落、title や見出し構造の不整合、構造化データのエラー、表示速度が悪化したページの検出と優先順位付け
- 長期的な機能開発
-
実装案の作成、別ブランチでの試作とテスト、時間を置いてからのコード再確認、Pull Request と変更説明の作成
ここでも役割分担が重要です。単純なリンクチェックや定型的なクロールは通常のスクリプトで実行し、Headlong は検出結果の原因分析と修正案の作成に使う方が合理的です。時間を置いて自分の成果物を見直せる点は、継続思考型ならではの特性といえます。
監視・cron・CI/CD との使い分け
Headlong を検討するときに最も重要なのが、既存の自動化手段との役割分担です。決められた処理を決められた条件で確実に実行するのは cron、監視ツール、CI/CD の役割であり、Headlong はその代替ではありません。Headlong が担えるのは、次に何を調べるべきかの判断も含めて、仮説、検証、見直しを継続する部分です。
| Headlong が向く仕事 | Headlong に向かない、または任せるべきではない仕事 |
|---|---|
| 原因が明確でない事象の継続調査 | 死活監視や即時アラート |
| コードレビューと改善候補の抽出 | 実行内容が決まっている定期処理 |
| 仮説を立てて検証を繰り返す作業 | 本番環境の自動変更 |
| 過去の調査履歴との関連付け | 高権限アカウントを使用する運用 |
| 収集済みデータの解釈と説明文の作成 | 機密情報を含むチーム共有 |
| 修正案や Pull Request の下書き | 人間の承認なしでの本番デプロイや障害復旧 |
右列は、機能として実行できないという意味ではありません。alpha research software という位置付けと、後述する失敗事例やセキュリティ設計を踏まえ、現時点では任せるべきではないと判断される範囲です。
継続運用で判明した失敗、コスト、セキュリティ
公式記事は成功例だけでなく、数週間の連続運用で発生した問題も公開しています。導入を検討する側には、こちらの方が判断材料になります。
自分自身のサービスを 3 回停止した
繰り返し発生した失敗として公式が挙げているのが、プロセスの自己停止です。Audel は自分自身のサービスを誤って 3 回停止し、再起動する仕組みがなかったため停止したままになりました。対策として自己停止を拒否する guard が追加されましたが、この guard 自体も自分以外のエージェントのサービスまで一致判定する不具合を抱えており、これも Audel 自身がテスト実行中に発見して修正しています。自律的に改善できる可能性と、自律的に壊す可能性は同じ設計から生まれます。
再帰的な shellm sub-run も期待どおりには機能しませんでした。30 秒間出力がないコマンドを停止する安全用ウォッチドッグに終了させられ、約 40 分格闘した後、Audel は sub-run をほとんど使わなくなりました。結果が思考へ統合された回数は最初の 2 日間で 64 回、その後の 12 日間では 12 回に減っています。なお、長期的な価値を測る評価手法は確立しておらず、現状の評価は主に定性的なものにとどまると公式も明言しています。
誰も使っていない時間にも費用が発生する
外部からの入力がなくても LLM API を呼び出し続けるため、誰もエージェントを利用していない時間にも API 費用が発生します。公式は、Laude Institute が Audel を運用している設定で、GLM または Grok を使用してバックグラウンドの思考を継続させた場合に 1 時間あたり 1 ドルから 2 ドルかかると説明しています。
この金額はあくまで公式の運用条件下での数値です。実際の費用は利用するモデル、思考の間隔、backoff の上限設定によって変わり、メッセージが届くたびに間隔がリセットされるため利用頻度にも左右されます。月額を見積もる場合は計算条件を明示し、公式の実測値と自分の推計を混同しないことが重要です。
セキュリティと情報分離の問題
Headlong はエージェントが生成した Bash を実際に実行し、各チャットから入ったメッセージは加工されずにコンテキストへ入ります。公式のセキュリティドキュメントは、この構造からプロンプトインジェクションがどのチャネルからも常に成立し得ると明記しています。
参考: Headlong deploy/SECURITY.md（GitHub）
“Prompt injection is therefore always possible, from any channel”
（したがってプロンプトインジェクションは、どのチャネルからも常に成立し得ます）
https://github.com/laude-institute/headlong/blob/main/deploy/SECURITY.md
チーム利用では情報分離の問題が加わります。Slack、Telegram、Web チャットの会話は、いずれも単一の mind log を共有します。ブリッジは自分の名前空間宛ての応答だけを転送しますが、思考そのものが共有されているため内容は行き来します。ある利用者が伝えた内容が、別の利用者への回答に現れる可能性があります。公式も、公開チャンネルに投稿できない情報は伝えないよう求めています。
連携部分にも既知の課題があります。Slack ブリッジでは、トークンを保持するルートの .env がエージェントの実行ユーザーから読めるため、インジェクションを受けたエージェントがトークンを読み取ってボットとして投稿し得ると公式が説明しています。エージェントは外部通信で情報を送信できるため、そもそも秘密情報を持たせないことが最も確実な対策です。
Headlong は Docker が利用可能な場合、生成したコードをコンテナ内で実行します。ただし、Docker を使えば安全になるという理解は正確ではありません。コンテナはホストへの影響範囲を狭める手段であり、マウントしたディレクトリ、渡した認証情報、外部通信までを自動的に保護するものではありません。公式も、エージェントが触れられるのはマウントした内容と渡した認証情報であると説明しています。
安全に検証する条件と業務利用の判断
ここまでを踏まえ、検証する場合の前提条件を整理します。公式が案内するインストール方法はワンライナーですが、内容を確認してから実行する手順も同じドキュメントに記載されています。
専用 VM か、破棄前提のコンテナを用意します。公式は長期稼働用のコンテナ実行例を提示しており、使い捨てにする場合は --name と --restart を外して --rm を付ける方法が案内されています。ホストディレクトリのマウントは最小限にします。
docker run -it --rm -p 8080:8080 buildpack-deps:curl \
bash -c 'curl -fsSL https://headlong.ai/install.sh | bash; exec bash'公式のワンライナーは curl -fsSL https://headlong.ai/install.sh | bash ですが、ダウンロードして内容を読んでから実行する手順も記載されています。初回はこちらを推奨します。API キーは専用かつ利用上限付きのものを使用します。
curl -fsSLO https://headlong.ai/install.sh
less install.sh && bash install.sh --init実行前に停止方法を確認しておきます。headlong-killall はマシン上の Headlong 関連プロセスをすべて停止する手段で、--dry-run を付けると停止対象だけを表示できます。導入状況の確認と削除にも公式のスクリプトが用意されています。
headlong-killall --dry-run
headlong-killall手順の出典は公式のインストールドキュメント https://github.com/laude-institute/headlong/blob/main/docs/install.md です。あわせて、環境面では次の条件を満たしたうえで検証することをおすすめします。
- 機密情報を含まないダミーデータだけを扱わせる
- 本番環境と分離したリポジトリを対象にする
- クラウドや GitHub の認証情報を安易に渡さない
- 実行時間、API 費用、外部通信に制限を設ける
- ログと trajectory を定期的に確認する
- 自動変更ではなく、レポートまたは Pull Request の作成までに役割を限定する
業務利用できる段階かという問いには、現時点では限定的という評価が妥当です。alpha research software であることを公式が明記し、連続運用では自己停止や guard の不具合が発生し、長期的な価値を測る評価手法も確立していません。一方で設計思想と失敗事例の公開は透明性が高く、調査系の作業への適用可能性は現実的です。現実的な役割分担は、読み取りから調査、仮説、隔離環境での検証、修正案または Pull Request の提示までを任せ、本番反映は人間が承認する範囲です。
参照した一次情報
まとめ
Headlong は、外部入力がない間もエージェント自身が次の思考を選び続ける persistent agency を中心に設計された、オープンソースのエージェント基盤です。監視ツールや cron の代替ではなく、原因が明確でない問題を継続的に調査し、過去の履歴を参照しながら仮説と検証を繰り返すための研究基盤として位置付けられます。応用可能性はある一方、公式が alpha research software と明記しており、本番環境を直接操作させる段階ではありません。
- 外部入力がなくても自ら次の wake-up を予約する自己駆動ループ
- コアは約 9,900 行の Bash で、ライセンスは Apache License 2.0
- 公式が alpha research software と明記する研究段階のソフトウェア
- 決まった処理の定期実行は cron や監視ツールの方が確実
- 生成した Bash を実行するため隔離環境と上限付き API キーが前提
- 全チャネルが単一の mind log を共有し、利用者間の情報分離は成立しない
- 現実的な用途は調査と修正案の提示までで、本番反映は人間が承認
以上、最後までお読みいただきありがとうございました。
