2026 作業日誌

ここ数日はかなり忙しかったため、記録を残していませんでした。しかし記録を止めるわけにはいかないので、今から再開してまとめて記録します。

忙しかった以外に、なぜ記録していなかったのか。

1. 心の中で、記録するには最低30分以上かけて一日をまとめなければならないという恐怖があったためです。これは日々の記録に対して負担や恐れを感じてしまい、良くない傾向です。
2. 普段は一日が完全に終わってからその日の記録を始めるようにしていますが、よく考えるとこれは少し人間らしくありません。なぜなら今の私は、寝る時間になったらすぐに布団に潜り込むからで、やりたいことを本当に全て終えてから寝るわけではないからです（そんな時が果たしてあるでしょうか？）。その結果、時間がある時に記録せず、本当に記録すべき時にはすぐに布団に入らなければならなくなります。そこに1の問題も加わります。

この二つが重なって、記録がどんどん溜まっていきました。

1. 今日やったこと：

   正確には、ここ数日やったこと

   1. scの勧めでneovimを使い始めました。なぜ使うのか？nvim-orgmodeが本当に実用的なorg-modeになったようで、同時にemacsに飽きてきたからです。

      • 延々と続くアップデートの失敗
      • 理解不能なデバッグとエラーメッセージ
      • 私にとっては負担が増えるだけで役に立たない柔軟性
      • Emacs Lispは理解できないし、理解したいとも思わない

      長年、orgmodeを使うために上記の点に耐えてきましたが、他の場所ではorg-modeをうまく使えませんでした。今、nvim陣営に代替案が出てきたのですから、試さない手はありません。

      もともと私は長年のvimユーザーで、emacsでもevil-mode（vimモード）を使っていました。そのため、vimを使うことが大きな負担だと感じたことは一度もなく、VSCodeやIntelliJ IDEAではvimがないと生きていけません。ですから、nvimに直接移行することは全く問題ありませんでした。

      障害がなくなったので、nvimのエコシステムを調べてみました。nvimはvimscriptという過去の負の遺産がなく、設定言語やプラグイン言語として直接Luaを使用しています。そのため軽量に始められ、コミュニティも非常に活発です。現在、neovimのプラグインシステムは lazy.vim というシステムに統一されています。nvimはプラグインと設定システムの設計において、vimが抱えていた問題点を大胆に革新したようです。vimやemacsには似たような統一を目指す試みが数多くありましたが、コミュニティが分散しすぎて、成功したものはなかったように思います。

      そこで早速lazyVimを試してみました。すると、なんとまるでVSCodeを手に入れたかのような感覚で、しかもそれがターミナル内で動作するのです。これがどれほど快適か、お分かりいただけるでしょうか？

      今や、真新しい基盤の上に構築された強力な旧支配者を手に入れました。設定も驚くほど簡単で、柔軟性と利便性が絶妙なバランスで収束しており、以前の悩みはほぼすべて解決されました。

      ほとんど時間をかけずに、かなりの数のワークフローをこれに移行しました。現在はtmuxで5つのウィンドウを開き、各ウィンドウで特定のフォルダ配下にnvimを起動しています。nvimの左側にはディレクトリツリー、中央にはコード、右側にはopencodeとターミナルを配置しています。

   2. legionをバージョンアップしました。legionmindスキルのテキスト量を大幅に削減しました（約4,000行削減）。現在のところ、私が気を配るべき箇所が減ったように感じますが、最近比較的賢いモデルを使っているからなのか、それともこのバージョンのlegionmindが本当に賢くなったのかはわかりません。

   3. openclawを構築しました。minimax 2.1はまだ少し賢くありませんが、個人アシスタントとしてはopenclawで十分だと思います。なぜなら、基本的には記憶機能付きのChatGPTに手足（私のPCを操作できる機能）が加わったようなものだからです。

   4. Yuanにhttp-proxy機能を追加し、メトリクスなどを追加しました。

2. 何か考えていること

   AIに文章を書かせることは、あまり原理が分かっていないコードをデバッグするのに似ていると感じることがあります。動作を繰り返しテストしたり、ログを出力してデバッグを補助し、あちこちを修正して、最終的に満足のいく結果が得られるまで試行錯誤します。この感覚の由来を探ってみます。

   AIを使ってコードを書くプロセスは、人間がプロンプト（具体的な指示を含む）を入力し、AIがその指示の背後にある暗黙の指示や情報を理解し、正しく作業を完了してくれることを期待するものです。

   AIに伝えたい指示を階層化できます。最上位は今回のタスクの指示です。その下には、このソフトウェアプロジェクトで行われたいくつかの技術的決定、トレードオフを検討した上でこのプロジェクトの一部に適用されるベストプラクティスがあります。さらにその下には、プロジェクトが解決しようとしている問題領域の背景情報があります。さらにその下には、AIを使うソフトウェアエンジニアリング自体の専門的な背景知識、個人の好み、技術的嗜好、スタイルの好み、過去の経験、思考方法の蓄積があります。最下層には、この世界の背景知識があります。

   AIとの対話の中でAIに明確に伝えられるのは、実際には今回のタスクの指示だけで、あとはAIが十分な世界背景知識と問題解決に必要な背景情報を持っていることを期待するしかありません。

   したがって、タスクのコンテキストが十分に小さく、指示が極めて明確で、過去の制約がなければ、AIは簡単に高品質なタスクを完了できるはずです。大量の暗黙的な背景情報があると、意味不明な結果を生み出しやすくなります。

   Legionmindが目指すのは、AI自身にこのプロジェクトと問題領域に関する背景知識とベストプラクティスを蓄積させることです。そのためには、AIが優れた論理的思考力と記憶力（コンテキスト容量）を持つか、あるいはAI自体が豊富な世界背景知識を持っている必要があります。これらを超えるものは、AIではどうにもなりません。

   —

   それから、nvimにもっと早く出会っていればよかったと強く感じています。

3. 明日やること

   明日はscの新居を見学に行き、一緒にボードゲームをします。ついでにsyにスキー用品を見せてもらいます。

zl が来て、情報量が非常に多かったので、しっかり消化する必要があります。ボードゲーム「悲劇の循環」をプレイしましたが、ルールの理解に3時間も費やしました。最後のシナリオで私が悪役の劇作家を演じたとき、ようやくこのゲームのスイートスポットを体感でき、最終的に私の完全勝利でゲームは終了しました。

本日は自制の一日でした。私は25歳を過ぎてから、感情に対して明らかな成長を感じています。それは、感情の外側に明らかに一条の理性がコパイロットとして伴っているということです。この理性が、感情の巨大な反応炉の中に制御棒を一本設置しているようなものです。この制御棒がなければ、感情は制御不能に陥り、自励的な連鎖反応を引き起こし、取り返しのつかない結果を招く恐れがあります。この制御棒の作用により、何を言うべきか、何を言うべきでないか、何をすべきか、何をすべきでないか、どの決定を下すべきか、どの決定を下すべきでないかが明確になりました。これは私にとって喜ばしい変化です。

1. 今日やったこと：

   1. 本日、legion を使用して yuan の http proxy の設計と実装を行いました。使用感はかなりスムーズだと感じました。途中でその設計をレビューし、ある一点（利用可能な terminal の選択方法）について修正を加えた後、agent に委ねて一気にやらせたところ、効果は非常に良好でした。
   2. また、legion を使って midas の自動更新を行う作業も試みました。しかし、AI は一貫して性能が悪く、私の要件を正しく理解できず、@yuants/protocol の使い方も正しく理解できませんでした。いくつか疑わしい方向性があります：AI の知能が不足している（deepseek はやはり賢くないのかもしれません）、レビューが十分に厳格でない、あるいはドキュメントや知識ベースが十分に整備されていない、のいずれかです。
   3. 夜、アラートで起こされました。host が理由なくダウンしたのです。どうやら CPU 使用率のピークにより、host が自力で回復できない状態に陥ったようです。host のログはめちゃくちゃで、私の評価としては「アラートは有用、ログはクソ」です。記録しておきます！

2. 考えたこと：

   1. 入浴中に、現在の私と AI の協業における最も重要なポイントについて考えました。一つは AI agent 自身のサービス可用性です。実行中に勝手に終了したりしないこと。ちなみに、ralph loop は基本的に乱暴な再試行を繰り返すことで可用性を高めています。もう一つは、AI が出力した結果をどのように受容するかです。例えば、部下が上司に報告する際には、PPT や場合によっては専門の中間管理職という「高価な伝声管」が必要です。AI から人間への報告が、ただベタ書きの Markdown やコードだけに限定されるべきでしょうか？AI のレポートの各項目に artifact へのリンクを付けることはできないでしょうか？この部分を専門に担当する Citation Agent があればどうでしょうか？

      ただし、現在の私の AI の使い方は非常に限定的で、コードタスクに集中しています。

   2. なぜ私がすでに multi-agent システムを持っているにもかかわらず、このシステムが確実に失敗に向かっているのか、じっくりと考えました。前の推測では、主に三つの可能性があると述べました。

      1. AI 自身の知能レベル
      2. 人間のレビューが不十分
      3. 知識ベースが不十分で、AI が迅速に立ち上がるためのより正確な情報を提供できない

      これらについて考えてみます。1 番は考えるまでもありません。2 番の方向に努力すれば、確かにますます詳細な RFC ドキュメントに頼って、後続のステップに十分に正しい方向性を与えることができます。しかし、このような開発方法は、まるで ウォーターフォール型 開発モデルに戻ったかのようです。線形のフローで作業を進めることになります。

      要件分析 -> バックエンド設計 -> バックエンド開発 -> フロントエンド開発 -> 結合テスト
      

      その要因は、技術面と組織・プロセス面の二つがありますが、組織・プロセスの面が 主たる要因 です。

      技術面では、タスク間に自然な依存関係が存在します。例えば、フロントエンドはバックエンドがインターフェースを提供するのを待たなければ開発を開始できず、バックエンドもプロダクトが CRD を書き終えるのを待たなければ作業を開始できません。

      人間の組織として、ウォーターフォール型開発モデルには次のような問題があります：効率の低さ、品質リスクの顕在化の難しさ、柔軟性の低さ、チーム内の対立など。一方、私と AI との協業の仕方においては、効率やチーム内の対立は AI の世界にはそもそも存在しません。まるで私と AI が異なる時間軸の実体であり、私の一日が AI にとっては一年のように感じられます。効率が低いとトークン消費が多くなるかもしれませんが、それは今私が最も気にしている問題ではありません。私が実際に直面している問題は、要件や事実の誤解による品質リスクと、柔軟性の低さです。

      AI の能力を最大限に活用しつつ、自分自身を最大限に解放する方法を考えなければなりません。人間同士の相互協力の経験に基づけば、私は指揮系統の上位ノードとなり、安心して AI に仕事を任せつつ、AI がレールから外れないようにする必要があります。

      最も重要な二点：

      1. 意図の一致
      2. 階層的な検証

      これについてはさらに深く考える必要があります。もっと実際に使ってみて、味わう必要があると感じています。

   3. 私は、自分が「ハンマーを持てば釘を探す」ような状態に陥る悪い面に注意する必要があります：経路依存、出力が理解を上回る、という点に。

3. 明日の予定は？

   明日 zl が来るので、運動をして、食事をして、ボードゲームを楽しむ予定です。

今日散髪に行ったところ、戻ってきたらシステムが不安定になっていました。結局、鸡哥が同じサービスのターミナルを2つ起動し、互いに競合したことが大きな問題の原因でした。

1. 今日やったこと：

   1. クラスターをNATの背後に移行しようと試みました。もちろん新しいlegionを使用して実行しました。操作は以下の通りです：

      • まずkopsクラスターを修正し、新しいVPCを作成しました。サブネットとして172.21.0.0/24と172.21.1.0/24を使用しました。そしてトラフィック出口用のNATを作成しました。

        当初は10.0で始まるサブネットを使う予定でしたが、AWSがそのCIDRの作成を許可しなかったため、172.21で始まるサブネットに変更しました。ここで注意点があり、clusterリソース内で既存のロードバランサーを対応するVPCに向ける必要があります（元々は暗黙的にデフォルト指定されていましたが、CIDRを追加したため手動で指定する必要がありました）。

      • 次に新しいインスタンスグループを作成し、新しいVPCに向けました。途中、小さなトラブルがありました。新しいIGにS3権限が付与されていなかったため、手動で追加したところ、ノードは正常にクラスターに参加しました。

      • 次のステップは、手動でサービスを新しいIGに移行することです。

      • 最後に既存のIGを廃止しました。

      完了した後、クラスターの出口トラフィックが1つのIPだけになってしまい、IPレート制限を行っているサービスに大きな負荷がかかってしまいました。やむを得ずロールバックし、まずHTTPプロキシの機能を実装してから次のステップに進む必要があります。

   2. マルチエージェントは、Midasの純資産を自動更新するスクリプトの実践に使用されました。Deepseekが時間をかけて書いてくれましたが、私はかなり満足しています。ここに核心的な問題があります。設計の初期段階で誤りに気づかなかった場合、膨大なトークンと時間の浪費が待っています。なぜなら、エージェントの作業はそれほど速くないと感じたからです。

      現在、これらのコーディングエージェントはまだ初期的で、ネットワーク問題などでよく途中でクラッシュして終了します。長期間実行される本格的な作業を任せるには、SLI（サービスレベル指標）がまだ不十分です。これは機会でもあると考えられます。簡単に考えると、これにはソフトウェアエンジニアリングの高可用性などに関する知識が必要です。

2. 考えたこと：

   今日はあまり考えがまとまらず、すべて上記の節にインラインで書きました。

3. 明日の予定：

   1. YuanのHTTPプロキシ機構を設計する。
   2. デプロイ後にクラスターを再度移行する。

今日は11時までぐっすり眠り、全身が軽くなった気がします。こんなに自由に寝たのは久しぶりです。

1. 今日やったこと：

   1. node-unitの新バージョンをリリースしました。安心してリリースできた理由は、十分なエンドツーエンドテストを実施したからです。具体的には、DockerでTimescaleDB（PostgreSQL 17）を起動し、2つのnode-unitを起動して、データベースに21個の@yuants/portalを挿入し、最終的に1対1の状態に収束するテストを行いました。

      このテストでは、未割り当てのdeploymentが多数ある状態で2つのnode-unitを起動すると、交代でdeploymentを獲得する様子を観測できます。本当に不足している点としては、CPU・メモリを実際に占有するワークロードと、何らかの理由でnode-unitがオフラインになるシナリオが挙げられます。

   2. 新しいマルチエージェント版のlegionmindを使用して、Yuanでvendor-gate earnアカウントの出力フローの問題を解決しました。エージェントにまずlegionを使ってドキュメントを作成させ、以下のドキュメントを出力させました。

      .legion/tasks/vendor-gate
      ├── context.md
      ├── docs
      │   ├── api-doc.md
      │   ├── pr-body.md
      │   ├── report-walkthrough.md
      │   ├── rfc.md
      │   ├── spec-bench.md
      │   ├── spec-dev.md
      │   ├── spec-obs.md
      │   └── spec-test.md
      ├── plan.md
      └── tasks.md
      

      これは一応形になったワークフローだと思います。ただし、新しいマルチエージェントシステムと既存のlegionmindのドキュメント作成に競合がいくつかありました。各処理の境界を慎重に検討する必要があります。例えば、各ドキュメントの書き方の規範は個別のスキルに分け、legionmindはあくまでワークフローの説明にすべきです。各エージェントは、いくつかの小さなスキルをロードして自分の作業を補助できるようにするべきです。

      まだ不十分な点もあります。初回の作業で、アカウントフローを=account-actions-with-credential.ts=に出力してしまうミスがありました。これは、vendor-okxを参考にしてearnアカウントを接続するよう指示したためです。現時点では、okxのearnアカウントのみがアカウントとして接続されています。しかしAIは、その中にある時代遅れのプラクティスも学習してしまいました。現在の取引所接続の標準では、アカウントはすべて=provideExchangeServices=経由で公開するものであり、=provideAccountActionsWithCredential=で接続するものではありません。

      これらの知識は、新しいAIエージェントには備わっていません。このような知識をどうモデル化すべきか、またAIエージェントに対して、このようなプロジェクトコンテキストを外部脳としてどう提供すべきか。これは深く考える必要のある問題であり、明日じっくり検討したいと思います。

   3. 午後は料理をしてsyの友人たちをもてなしました。とても疲れました。明日は引き続き仕事をしようと思います。

2. 考えたこと：

   • 上記の通り、AIエージェントのためのコンパクトな外部脳をどう設計するか、慎重に検討する必要があります。最も簡単な方法としては、一連のAGENT.mdから始めることです。以前試しましたが、これらのドキュメント自体のメンテナンスオーバーヘッドもかなり高いです。ゴミと本当に記録に値する経験を区別するのは難しい問題です。今のところ、記憶は他のプロンプトと似ていますが、エージェント自身が記憶を更新するループを持っている点が異なります。最も重要なのは、AIエージェントの作業結果をどう評価するかです。

   • 上記に関連して、興味深い記事を読みました。自分の言葉で要約します。まず、エージェントの1ステップの作業に対する評価は以下のように分類できます。

     1. 静的ツール評価：コンパイラ、リンター、単体テスト、E2Eテスト
     2. モデル評価：別のLLMが定義したプロンプトに従って判断
     3. 人手評価：私が判断

     次に、エージェントの体系的な評価は2つに分けられます。

     1. 能力型：そのエージェントが何をできるかを問う。合格率が低い場合もある。例えばlegionを使ってより大きく難しいタスクを段階的に実行する場合、新しい境界を探索する感覚です。
     2. 回帰型：以前できたことを維持できているか。例えばタスクを繰り返しテストし、安定して実現できることを確認します。

     新しい能力が導入されたら、能力型から回帰型に移行すべきです。

     この記事では、pass@Kとpass^Kという2つの重要な指標も挙げられていました。

     • pass@k：k回の試行のうち少なくとも1回成功する。試行回数が多いほど、少なくとも1回成功する確率が上がる。適用例：「少なくとも1つの有効な解が見つかればよい」というシナリオ。
     • pass^k：k回の試行すべてが成功する必要がある。試行回数が多いほど、一貫性を維持するのが難しくなる。適用例：ユーザーが毎回信頼できるプロダクションエージェントを期待するシナリオ。

     参考記事：こちらの記事

   • 体力がまだ不足しています。午後少し作業し、夜料理をしただけで疲れを感じました。いつになったらCZのように眠らなくてもよくなるのでしょうか？

3. 明日の予定：

   1. 評価エージェントのモデルを検討し、マルチエージェントシステムを引き続き改良する。
   2. クラスタのセキュリティ問題。必ず取り組む。
   3. legion-github-bridgeの対応。

今日は少し風邪気味で、頭痛がして生産性が低かったですが、毎日のまとめを始めてよかったと思っています。

1. 今日やったこと：

   1. AIの助けを借りてマルチエージェントシステムを設計しましたが、まだ十分に洗練されていません。
   2. legionmind-github-bridgeがまた一歩前進しました。
   3. node-unitのプリエンプション設計と実装を修正しました。以前は特定のnode-unitが失敗した場合、その下の全てのdeploymentがクリアされていましたが、現在は一つずつクリアするようになりました。
   4. 先物・証券会社の口座開設（中金所）の試験を受けてきました。なんと全画面でカメラをオンにし、最小化や画面切り替えが禁止されていました。しかし、無限に再挑戦できたので難しくはなく、95点で見事合格しました。

2. 考えたこと：

   私の目標は、できるだけ少ない摩擦でエージェントを自律させることです。現在のワークフローは以下の通りです。

   1. legionmindは開発作業のSOPとして機能しており、エージェントスキルです。私はエージェントスキルが好きです。
   2. opencodeをエージェントの実体として使用しており、その中のbash / tool calling / langraph / command / subagentなどの機能を活用しています。もし将来opencodeをやめるとしたら、これらが実装すべき項目になります。
   3. 現在困っているのは、スキルとこれらのサブエージェントをどう組み合わせるかということです。

   一日中頭が痛かったのですが、夜になってようやくすっきりしてきました。一日の終わりにこれらの考えをまとめるのは良い方法ではないかもしれません。事実だけを記録し、明日の朝起きてから考えをまとめる方が良いかもしれません。

3. 明日やること：

   1. このマルチエージェントシステムを使って何かやってみます。Gateの資産管理口座に接続してみます。
   2. legionmind-github-bridgeを続けます。
   3. クラスタのセキュリティ、時間があれば。
   4. 作業時間の計測を再開します。（重要）
   5. 明日はsyの友達が遊びに来るので、作業時間が削られるかもしれません。