jolestar

codexデバイストークンでのログインが突然電話番号の認証を要求していますか？そして、openaiの電話番号がアカウント設定で見つからないことに気づきましたか？変更しようとしても、変更できる場所がどうやらありません。

エージェントに必要な基本ツールセット
皆さんがエージェントのツールセットについて話しているのを見て——シェルを提供すればすべて解決できるのでは？と思ったが、holonを作った後で気づいたのは、実はそんなに簡単ではないということだ。
読：なぜRead/Globを放棄し、すべてシェルに切り替えたのか
holonのツールセットは何度かバージョンアップを重ね、最終的にClaude Codeが提供するRead（ファイル読み取り）、Glob（パターン検索）といった専用ツールは廃止し、読み取りや検索はすべてシェルを通じて行うようになった。これはCodexの路線と一致している——CodexのExecCommandは一つのコマンドで済ませ、ファイルの読み取りはcat、コードの検索はrg、各"読み取り"操作に個別のツールを定義しない。
このやり方の理由は非常に素朴だ：シェルはLLMが最も馴染みのある「プログラミング言語」だからだ。モデルにReadツールのパラメータの意味を学習させるよりも、すでに何十億回も訓練されたシェルコマンドを書かせた方が効率的だ。専用ツールを増やすたびにモデルの認知負担は増すが、シェルというインターフェースにはモデルはすでに十分に習熟している。
しかし、すべてをシェルだけで済ませるには代償もある：出力の切り捨てだ。フレームワークはシェルの返り値が長すぎてコンテキストを圧迫しないよ

GPTとたくさんやり取りするうちに、自分も「収口」という言葉を使うのに慣れてしまった。
いくつかのタスクを終えた後でも、まだいくつかの細かいことが残っているときに、それを「残りのことを収口して」と伝えるのが自然に感じられる。
以前は「収口」という言葉を使わずにどう表現していたか、すっかり忘れてしまった😅。

AIコーディング時代においても、良いプログラミング習慣は依然として重要です
最近、あるエージェントのベンチマークを行っていて、AIにとってのプログラミングタスクの複雑さを開発者の視点だけで評価できないことに気づきました。
例えばリファクタリングのタスク：数千行の大きなファイルを機能ごとに十数の小さなモジュールに分割する作業です。
このタスクは開発者にとっては実はそれほど難しくなく、主な作業はコードの移動、インポートの整理、コンパイルの検証であり、初心者でもこなせます。
そこで、シンプルなタスクを使ってベンチマークを試みたところ、予想外の結果になりました。
Claude Codeはこのタスクが比較的大きいと判断し、一部を分割してPRを出し、Future workとして段階的に進める提案をしました。
私のエージェントは「強行突破」し、より完全な分割の方向に進めましたが、その代償も明らかでした：Tokenの消費はClaudeの数十倍に達し、その後も大量の時間をファイルの読み込み、コンパイルエラーの修正、再読、再修正に費やしました。
これにより、人にとって簡単に見えるタスクが、エージェントにとっては必ずしも簡単ではないことに気づきました。
人にとっては、多くの場合、「この部分を移動させる」だけのリファクタリングですが、エージェントにとっては、大きなファイルを

2つのエージェントのPRのやり取りを見て、なかなか面白いと思った。
開発エージェントはCIの最適化に関するissueを完了し、PRを提出した。
レビュアーエージェントは、タイムアウトのデフォルト値の変更がissueの範囲に合わないと判断し、拒否した。
開発エージェントはそのタイムアウトのデフォルト値を削除したが、その結果CIが通らず、一つのテストケースでエラーが出た。そこで、テストのsleep時間を少し変更してテストを通した。
レビュアーエージェントは、そのテストは非同期タスクのタイムアウトキャンセルのシナリオだけをテストしていると考え、変更後はテストの意味がなくなるとして再び拒否した。
開発エージェントはそのテストを修正しようとしたが難しかったため、テストをスキップにし、もともとこのテストは通らなかったし、元のCIにはカバーされていなかったと述べ、今回のCIのカバレッジに入ったのでスキップした。
最後にレビュアーはマージを承認した。
本当に人間みたいで、怠けたり、できるだけ簡単な方法を選んだり😅。少し前にAIエージェントに役割を持たせるべきか議論したこともあったが、基本的に万能だからだ。でも今はやっぱり役割が必要だと感じている。役割は責任を担い、その責任が優先順位判断や行動に影響を与えるからだ。

AIがエージェントタイプの製品を設計するとき、AIはしばしばエージェントの能力を過小評価しがちで、その結果、コードやプロンプトの制約条件を多く設けてしまい、エージェントの自由度が不足し、非常に硬直した印象になってしまう。後になって考えてみると、もしかすると現在のAIの訓練材料が、皆が前世代のAIを使った経験に基づいていることと関係があるのかもしれない。

2つの Agent を協業させるために、developer が PR を提出し、architector がレビューと PR のマージを担当します。これらを「github event」を購読して操作をトリガーさせます。ただし、両方とも私のアカウントを使っているため、しばしば自分が送ったものだと誤認されてフィルタリングされてしまいます。Agent に専用の Github アカウントを登録する必要があります。今後は、インターネットサービスも、Agent 用アカウントを手早く作成できる機能を提供すべきです。皆さんは現在、複数の Agent が協業するにはどうやっていますか？

コードXにツールを作成し、itermで動作しているコードXにメッセージを送ることができました。ツールは完成しましたが、メッセージを送信するだけで、実際に送信ボタンを押すことができません。文字列の連結「\r」やさまざまな組み合わせを試しましたが、うまくいきませんでした。
それから、itermのソースコードをダウンロードして調べたり、ネットで検索したりしましたが、結局のところ、やはりできないという結論に至りました。
itermが提供しているインターフェースはテキストを送信するだけで、キーボードイベントを直接送信することはできないため、送信を実現する方法はありません。私にtmuxだけをサポートし、itermは諦めるように勧められました。
諦めきれず、何度か自分で試行錯誤した結果、テキストを送信した後に、単独で「\r」を送るだけで😅。

UXC v0.13.1 正式リリース
今回のリリースでは、v0.13.x の2つのバージョンのアップデートをまとめており、UXCのリモートツールの安定した動作（Runtime）体験を一歩前進させました。
コア機能：
1. 直接TypeScriptクライアントコードを生成し、コマンドラインで探索・テストしたリモート能力を、強型付けされたコードとしてローカルアプリに統合可能。クライアント連携層を再作成する必要はありません。AIはCLIだけでなく、コード呼び出し能力も必要とします。
2. MCP設定の自動検出と既存のMCP開発者がシームレスにUXCに接続できるようにし、手動で設定を再作成する必要を排除。さまざまなMCP設定をCLIやskillに変換し、コンテキストのオーバーヘッドを低減します。
3. Linkコマンドにはソーススキル（Skill）メタデータが含まれるようになりました。AIエージェントの呼び出しコマンドは、それが対応するスキルモジュールや原始ドキュメントに遡ることができます。
その他の改善：
1. バックグラウンドデーモン（Daemon）のセッション可観測性を強化し、長時間稼働するMCPやランタイムセッションの検査・デバッグを容易にし、システムの信頼性を向上。
2. Artifact（成果物）と大容量レスポンスの処理メカニズムを統一し、大きなファイルや出力に遭遇した際も、シ

Worktree は一時的な実行ディレクトリとしてより適しています
以前は、皆さんよくやっていた方法は、まず worktree を準備し、そのディレクトリ内で Codex / Claude Code を開くことでした。初期のモデルはコンテキストや記憶が十分でないため、メインのワークスペース内で直接 worktree を作成させると、コンテキスト圧縮後に現在のディレクトリと作成された worktree ディレクトリを混同しやすく、最終的に混乱を招きます。
しかし、このやり方には副作用もあります。それは、worktree を長期的な作業空間として徐々に使い続けてしまうことです。問題は、worktree はもともとブランチに紐付いているため、時間が経つにつれてブランチの切り替えや同期、クリーンアップといった余計な手間に直面することです。
Worktree と独立したクローンの違いについて、多くの人はあまり明確に理解していません。その利点は「ディレクトリが増えること」ではなく、本質的に同じリポジトリを共有し、git オブジェクトライブラリを共有しているため、コピーコストが低く、ネットワークのクローンを再度行う必要もないことです。これは大規模リポジトリにとって特に便利です。したがって、一時的に並行して実行するディレクトリを作りたいだけなら、worktree は非常に適しています。完全に独立し

ブログをmdoriginに移行しました。AIのおかげで、自分のブログを再び活用できると感じています。
私はCodexに、「私の内容に基づいて、ブログのスタイルを提案してください」と頼みました。
Codexは2つのバージョンを提供し、2つのポートを開いてプレビューを見せてくれ、その理由も詳しく説明してくれました。
それで、私はmdoriginの内蔵テンプレートスタイルシステムを削除しました。テンプレートというものは、もともとAgent時代の産物で、主にスタイル変更の敷居を下げるためのものでした。
今はAgentが拡張機能を提供すれば十分です。サイトのスタイルはAgentに任せて、mdoriginはHTML / Markdownの構造、ルーティング、コンテンツの検索だけを担当します。
以前、ブログを書いていて面倒だった点があります：多くのシステムは画像や添付ファイルを専用の公共ディレクトリに置くことを要求します。
こうすればデプロイは楽ですが、執筆時には非常に違和感があります。記事は一つのパスで管理され、画像も別のパス、ローカルプレビューと最終公開時では見た目が一致しません。
mdoriginは画像、動画、添付ファイルも記事と一緒に管理し、Markdown内では相対パスを直接使用します。
公開時には、mdoriginがメディアファイルのサイズに応じて自動的にCloudflareのass

OpenClawのモデルをgpt-5.4に変更したところ、確かに能力は向上しましたが、少し冗長で長話になりすぎて、ちょっと我慢できなくなってきました😅。

GoogleはWorkspace CLIをリリースし、Drive、Gmail、CalendarおよびすべてのWorkspace APIをサポートしています。
少し見てみたところ、実現方法はuxcに似ており、schemaファイルを使って実行時にコマンドを出力する仕組みです。
npm install -g @googleworkspace/cli
AppleはAppleエコシステム向けのCLIをリリースするでしょうか？

AIとのやり取りがますます丁寧になってきました。以前は直接指示を出し、間違っていれば怒っていましたが、今ではAIが間違ったときには、「xxx、これの方が良いでしょうか？」と控えめに尋ねるだけです。😅

米国防総省とAnthropicの対立は、実は始まりに過ぎない。AI企業は本来「準主権レベルの能力」を持っているが、サプライチェーンや金融清算が制限されると、自分たちが独立していないことに気づく。重要な武器を握りながらも、単一の主権に完全に支配されたくない場合、唯一の道は大国間の博弈の中で第三の空間を見つけることだ。その時になって初めて、cryptoがすでにこのような主権を超えた生存のための道を整えていたことに気づく。

Codexがコードを書いていると、突然理由のわからないシステムにいくつかのサービスが追加され、作業ディレクトリに奇妙なデータファイルが現れ、システムからXcodeツールをインストールする必要があるとポップアップが出た。何かおかしいと感じて、もしかしてコンピュータがハッキングされたのかと疑った。結果、Codexがスクリプトを間違って書いてしまい、システムコマンドをすべて実行してしまった😅。Codexのサンドボックスモードはあまり賢くなくて、毎回すべての権限を与えざるを得ない。別の方法を考えなければならないようだ。

帰省して、家にあったいくつかのデバイスをTailscaleでプライベートネットワークに組みました。高性能デスクトップは量子化モデルを実行し、Rustのコンパイルを行い、Mac StudioにはOpenClawを展開し、懶猫はソフトルーターとして、SSHも通し、ネットワークのウェイクもすべて設定済みです。新幹線の中でリモートで龍虾に仕事をさせて、これらのデバイスをフル活用させようとしたところ、作業中に突然応答しなくなり、ネットワークウェイクも効果がありませんでした。電話で確認したところ、実は家の老人が省電のためにプラグを抜いていた😅。未来のAIが人類と戦争を始めるとしたら、最初の一歩は間違いなく電源スイッチを奪うことになるでしょう。