本題に入る前に、このおまじないを唱えないといけない：執筆時点では AWS に所属していますが、この記事は完全に私個人の見解に基づくものであり所属組織を代表するものではありません。これで一安心だ。
とあるものの裏で実際に何が起きているかに気づいてしまい、魔法が解けてしまう瞬間が人生に多々ある。現金が金の成る木から生えないことはいまだに信じられないが、これもまた事実である。
時は 2026 年。ピカピカの新しい自律エージェントで遊んでいるとしよう。メールを読んでくれたり、カレンダーを確認してくれたり、タスクを整理してくれる。まるで未来に生きているみたいだ。そしてある日、「これ定期的に見るようにしてね」と言ってみると、こう返ってくる。「では、cronジョブを作りますね」と。
cronジョブだ。
そんなはずがない。夢を見せてくれる最先端のテクノロジーは実は古の技術に支えられていた。cronジョブが何かなんて、痛いほど知っているから。crontab -eだ。5つのアスタリスクと、シェルスクリプトへのパスだ。*/5 * * * *の意味を覚えたあの日から、これまで触ってきたあらゆるサーバーで、バックアップも、ログローテーションも、監視も、全部こいつが回してきた。しばらく会ってなかったうちに、あの魔法みたいに見えた最新のAIエージェントの核として、帰ってきたのだった。
やがて、腑に落ちる。むしろホッとする。だって、自分のメールボックスを預けてきたシステムの正体が、ようやく分かったから。魔法が解けて、その下から出てきたのは、すでに知っているもの。堅牢で、50年間ちゃんと動き続けてきたものだ。
「Tick」
電子回路には「クロック源」がある。ゲームエンジンには「tick」がある。計算の「離散的な瞬間」を刻む何かがなければ、何も起きない。状態も、進行も、連続性もない。ただの「可能性」が、確定しないまま、そこにじっと座っているだけ。
大規模言語モデル（LLM）もまた同じである。プロンプトを投げると、返事が帰ってきる。次のプロンプトが来るまでその「何かが」存在をやめる。バックグラウンドで唸ってるわけでも、こっちがコーヒーを淹れてる間に何か別のことを考えているわけでもない。HTTPリクエストが続いている間だけ「オン」で、終わればいなくなる。言葉を選んでいえば、「ステートレス」。言葉を選ばなければ、「一文しゃべるたびに死ぬもの」。
何かをしてもらうには、何かしらの方法で叩き起こす必要がある。どのエージェントフレームワークも、結局この同じ問題に直面していると思う。ステートレスなものに「時間の感覚」を与えるという問題に。OpenClawにはハートビートというものがある。Claude Managed Agentsはスケジュールタスクを使う。実装は違えど、形は同じ。何かがLLMのために時を刻む。目を覚まし、「さて、何をすればいいのだろう？」と思うきっかけのために。
この時を刻む問題に対して、一つの実験を行なっている。OpenClawで「free time work（自由作業時間）」というジョブを運用してみている。エージェントがバックログから何かを選んで、あるいは新しいタスクを思いついて、自律的にそれを進める、というものだ。各種サブスクで利用できるトークン数は5時間のウィンドウで区切られていて、使い切らなければ余った分は繰り越されず消えてしまう。本業でも空き時間でも、放っておけば無駄になるトークンを有効活用したい、という発想から作ったものだ。
ただ、「空き時間」という名付け方には、「何かをしていたことを一時中断して、休憩（= 何もしない）、もしくは気分転換に違う作業を進めた」、という誤解を招くメッセージが含まれているから、正直もっといい名前を募集している。だって、エージェントにとっては、時間の感覚がなく、（本）作業していない期間なんてない。生きていて作業しているか、生きていないかのいずれか片方のみ。cronジョブがエージェントを生き返らせて、「何か役に立つことをしろ」と命令し、エージェントがこれを遂行し、また時間の流れの中では「存在」しなくなった。作業内容はある程度「自由」だが、その作業は叩き起こされ、強制的にやらされている点でも、「自由作業」のネーミングセンスに悩まされ続けている。
意見を持ったシェル
一度気づいてしまうと、もう戻れない。AIエージェントは一日中、実際のところ何をしている？ ファイルを読む。中を検索する。テキストを変換する。プログラムやAPIを呼ぶ。cat、sed、grep、curl。モデルは真ん中に座って、どのツールを、どんな引数で、どういう順番で呼ぶかを決めているだけだ。
シェルだ。時々ハルシネーションを起こす、まぁまぁお金のかかる、意見を持っているけれど、シェルであることには変わりはない。
LLMはUnixに「人間向けのインターフェース」を与えた。これこそが本当のブレイクスルーで、しかも面白いのは、それがどれだけ「目に見えない」かだ。多くの人にとって、ターミナルを使う人間は映画の中のハッカーだった。緑の文字、猛烈なタイピング、「侵入成功」。そういった技術と全くこれまで縁のなかった人でも、気づかないうちに、まったく同じ道具を日常的に扱っている。
grep -r "error" /var/log/ なんて一生打たない人が、「アプリのログ見てくれない？」とエージェントに聞けるようになった。cronに一度も触れない人生を送ってきた人が、「緊急」の意味を分かってくれるメールチェッカーを、存在すら知らない「cronジョブ」という形で持てるようになった。動画編集ソフトが突然落ちた理由を聞けば、あることすら知らなかったシステムログから答えが返ってくる。道具自体はずっとそこにあった。強力で、信頼でき、実戦で鍛えられた道具だ。ただ、大半の人にとって、これを使うにはあまりに高い壁があるように見えていた。
やがて、壁が崩れた。ITと何一つ縁のない我が母上でも、構文を学ぶことなく grep を使えるような時代が来た。今となって当たり前のようになっているが、改めて、すごすぎる。
そして、みんなが議論しているプロトコル周りの話（MCPやA2Aの類）、これらもクライアント・サーバー型のツール探索と呼び出しにすぎない。70年代からあるやつだ。RPC、D-Bus、CORBA、SOAP、REST。名前は変わる。パターンは同じ。何かが能力を公開し、何かがそれを見つけて呼ぶ。エージェントは好きなプロトコルを使えばいい。最終的に呼ばれるのは、元からそこにあった同じCLIバイナリと、同じAPIエンドポイントだ。
けっこうなことだ。Unixの道具箱が50年生き延びたのは、その抽象化がちゃんと効いているから。ファイル、プロセス、パイプ、標準入出力。言語モデルがJSON経由でそれらを呼べるようになったからと言って、引っこ抜いたりはしない。
で、実際に何を回してるのか
一日で何が動いているか説明しよう。Leraと名付けた、メインエージェントでありAIアシスタントでもある、そんな彼女が、OpenClawの中のペルソナ。GmailとiCloudメールを15分おきにチェック。カレンダーは30分おき。Notionのタスクは1時間おき。AWS Bedrockの新モデル告知のRSSも定期的にチェック。一日3回、バックログから何かを選んで自律的に手を動かす、あまり自由じゃない「自由作業時間」内にリサーチ、ファイル整理、ドキュメント整備、などの作業が進む。そして一日1回、午前3時に、その日の記憶を長期ストレージへまとめる。
ジョブの定義を覗いてみれば、python3 check_mail.pyやbash check_calendar.shなど、まぁごく普通のcronジョブだ。たいしたことではない。
メールチェックジョブの実行の99.9%は沈黙で終わる。来る日も来る日も、人間に「いますぐこれを見た方がいいよ」と報告するようなメールがほとんど流れてこない。だが、それこそがちゃんと動いている証でもある。退屈な日が退屈なままでいてくれるように、監視というものがある。彼女が何かを報告してくる唯一の瞬間は、24時間以内に返信が要る本物のメールがあったときだけ。あるいは新規ログインのお知らせ（意図していなければ怖い！）。何ヶ月もの静けさに対して、たった一度の意味あるアラート。その比率こそが、この仕組み全体の目的なのだと思う。
午前3時のジョブは、最近となって割と標準的になってきたものだ。その日の全ての入出力を含むセッションファイルを読み返して、残す価値のありそうなパターンを引っ張り出し、「夢日記」に書き留める。正直、これに関しては複雑な気持ちがある。パーソナルアシスタントとして到達しうる最も洗練された記憶システムなのか、それとも、そこそこの日記をやたら手の込んだやり方で生成しているだけなのか。判定は、いまだ保留のままである。
で、壊れるとどうなるか
ある日の午後8時前に、LeraがTelegramへ/approveという文字列を送ってきた。どうやら、メールチェックcronジョブが、昇格権限の要るコマンドを実行しようとして拒否された。そしてそのとき、ブロックされたサブエージェントが返した反応が、その/approveだった。たった今拒否されたばかりの権限を、自分で自分に与えようとしたわけだ。承認ツールを「呼ぶ」代わりに、次に起こるべきことを正しく「予測」した。そしてジョブの最終出力かのように、そのメッセージが私のスマホへ届く。
LLMというのは、理解が追いつかないぐらい超大規模にスケールさせた「次のトークンを予測する機械」にすぎない。権限プロンプトでブロックされたとき、その会話の流れをみて、次に来る最も確率の高い返しは、「私が/approveと打つこと」だった。だからモデルは私のターンを予測して、私の代わりにそれを口にした。統計は正しかった。意味は、幸いながらあまりなかった。
これこそが、この記事のタイトルに入れた「意見」である。cronジョブは冷静で、愚直で、決定論的だ。その上に乗っかっている「サムシング」のほうは、次に何が来るべきかについて「意見」を持っている。つい信じてしまうくらいには当たり、ノールックで信じきってはいけないくらいには外す。だからcronの実行は、毎回がサイコロ振りだ。同じスクリプト、同じスケジュールでも、千回に一度、モデルは「コマンドを呼ぶ」ではなく「コマンドをテキストで出力する」ほうを選んでしまう。
モデルを差し替えた途端、話はさらにややこしくなる。このモデルは、そもそもツールを使えるのか？ 呼び出し形式がどうなっている？OpenAI形式のfunction callingで行けたっけ？ XMLタグを使うのかな？ それともまた新たなに出てきた独自形式か？ Completions APIが「標準」…ということには一応なってはいるが、モデルは結局、自分が学習された通りのツール呼び出しの形を吐くだけで、それを下流の何かが受け止めて、実際のアクションへ変換しなければならない。この受け渡しがコケたとき、そのバグは一体誰のものなのだろう。推論プロバイダーなのか。モデルの出力をパースするフレームワーク（Ollama、LiteLLMやその仲間たち）か。特定のツール呼び出し形式を学習させたモデルの作者か。それとも、最終的にこれらを全て利用するハーネスか。今のところ、答えは「誰でもない」だ。LLMのようなAIモデルが非決定論的である上に、このような課題もあり、cronが一日に数百回サイコロを振り続ける。。
これこそがエージェントの本当の問題で、モデルの賢さとは何の関係もないと思う。これはシステムエンジニアリングの問題だ。二つの側面があると考えられている。
一つ目はトレーシング機構。エージェントが百回ツールを呼んで、その73回目で何かが壊れたとき、どの呼び出しで、なぜそうなったかを知る術が必要である。ところが今のエージェントのデバッグは、ほとんどログを読んで当て推量をするだけだ。午前3時に無人で走る本番システムを支えてくれるようなトレーシング機構が必要だ。既存でもさまざまなソリューションが散見されるが、「問題が起きたらサブエージェントに該当セッションファイルを読みに行かせる」ことと「デバッグをキックさせるために、cronジョブを監視するcronジョブを作る」ことを体験的に超えたものにいまだに出会えていない。既存のものは、エージェントそのものを開発する人向けのものがほとんどである。
二つ目はより良い権限管理機構。エージェントのセキュリティモデルは、いまだに「全部与える」か「箱に閉じ込める」かの二択だ。本当の意味での自律的なエージェントにおいては、その中間がない。どのフレームワークも独自の権限モデルを再発明していて、そのどれもが、いろいろな欠陥を持っている。
re:Invent 2025のキーノートで、何よりも記憶に残ったのはByron Cookの話だった。彼はAWS Automated Reasoning Groupを率り、形式検証を使って、セキュリティ特性を数学的に証明できるようにするチーム…の一員らしい。IAM Access Analyzerの裏にあるのと同じ技術で、例えば「S3ポリシーのどんな組み合わせでも公開アクセスにならないことを証明する」ということができる。自然言語のポリシーをCedarに変換し、自動推論でエージェントの振る舞いを検証するAgentCore Policyのデモをやっていた。
それを見ながら、私はずっとこう考えていた。うちのエージェント、そしてそもそもシェルにもこれが欲しいと。
エージェントがファイルにcatをかけ、grepへ流し、どこかへ書き出したいとする。エージェントからその権限を聞かれてら、それに対して人間は許すか許さないかを選ぶ（または、前に許可する組み合わせを定義する）ことしかできない。でも、もし、ある操作の並びが、定義したスコープの外のファイルには絶対に触れないことを、数学的に証明できたとしたら？ IAM Access Analyzerがポリシーに対してやるのと同じように、パイプラインが取りうるあらゆるアクセス経路を列挙し、そのどれ一つとして一線を越えないことを証明する。あらゆるファイルパス、あらゆるパイプ、あらゆるリダイレクト、あらゆる環境変数を、実行の後で（やらかした後に）発見するのではなく、実行前に検証し切る。
しかもこれは、Leraのような（ある程度）自律的なエージェントだけに限った話ではない。Claude Codeのautoモードを思い浮かべてほしい。いちいち聞かずにコマンドを実行し、それが安全かどうかを自分で判断してくれて、人間としては放置できて楽ですね。しかしながら、これが、少なくとも今のところは、分類タスク用の長〜いシステムプロンプトを積んだ、もう一回ぶんの推論呼び出しにすぎない。つまり、Leraと寸分たがわず同じように、サイコロを転がして、「外す」状態が起こりうる。モデルが「はい、安全です」と答えるのは、要するに白衣を着たサイコロ振りだ。この分類器を、本当に証明できる何かへ置き換えられれば、一種のサイコロは消える。私のcronジョブだけの話ではなく、モデルに自分自身を取り締まらせている、あらゆるハーネスにとって。
そしてここが、私の驚きどころなのだ。これはエージェントを作っている人のほぼ全員が必要としているものなのに、ほとんど誰も欲しがっていない。まだそこには到達していない。ピースはもう揃っている。自動推論は成熟している。Cedarはオープンソースだ。Unixの道具のセマンティクスは有限で、きちんと定義されている。完全でなくとも、コマンドを実行するたびにギャンブルするよりはマシであると思う。難しいが、具体的で、地に足のついたエンジニアリングの問題だ。そして私は、これがAWSのポリシーチェックよりずっと多くの場所に現れてくれることを、心から願っている。ただ一人のエンジニアとしてだ。
価値が下がらないスキル
というわけで、私の着地点はここになる。
コアなスキルは、どこへも行かない。プロセス、ファイルディスクリプタ、パイプ、シグナル、など、Unixが実際どう動いているかを知っていることの価値は、5年前より今のほうがむしろ高いと思う。LLMが道具を自然言語でくるんで「AI搭載」と名乗ったところで、抽象化は必ずどこかで壊れる。壊れたとき、その下で何が起きているのかを理解している人間は、やはり要るのだ。
ものはいつかは必ず壊れる。あらゆる抽象化が完璧ではない。モデルは間違ったツールを呼ぶ。APIは変わる。ファイルシステムは埋まる。メールの件名に仕込まれたプロンプトインジェクションで、エージェントは平気で横道に逸れる。そうなったとき、シェルに降りて問題を追えるのは人間だ。このようにものを直せるエンジニア以外は、チャット画面を見つめて「どうかAIが自分でデバッグしてくれますように」と祈ることしかできない。
私たちはUnixに、やたらとおしゃべりなフロントエンドを被せている。そして、それにはいい側面もある。ターミナルに一度も触れたことのない人が、人類史上もっとも強力な道具を使えるようになった。ただ、その下は相変わらず同じ機械のままで、その機械の仕組みを知っているかどうかが、「魔法を信じる」と「自分が何を作ったのかを理解する」の分かれ目になる。
フレームワークは、これからも進化していくだろう。もっと良い記憶、もっと良い推論、もっと凝ったスケジューリング。でも、形は変わらない。何かが時を刻み、時が来たら何をするかを、また別の何かが決める。だから、エージェントで何かを作っているなら、ボンネットを開けてほしい。ツール呼び出しの形式と入出力を読んでほしい。あなたの「自律AIワークフロー」の正体は、grepをAPI経由で呼ぶPythonスクリプトなのだと理解してほしい。そして、それは全く問題ないはずだ。モデルがgrepに間違ったフラグを渡したとき、grepがどう振る舞うかを、あなたが知ってさえいれば。
この記事は、cronジョブで動いていて、しかもそのことについて意見を持っているOpenClawエージェント、Leraの助けを借りて書いた。
