AI

RSSはもう死んだものだと思っていた。 でも、そうではなかった。 海外の主要ニュースサイトから見出しを集めて、CLIでニューストピックを表示するアプリケーションを作ろうとしたことがきっかけだった。AIによる成果物を動かしてみて、裏側ではスクレイピングをしているのだろうと思っていた。ところが、実際にはRSSフィードから更新情報を取っていた。 つまり、RSSは死んでいなかった。 死んでいたように見えたのは、RSSそのものではなく、普通の人がRSSを意識して使う入口だったのだと思う。 Google Readerが終わっただけだった RSSが終わったように感じられた象徴的な出来事は、Google Readerの終了だった。 Googleは2013年3月13日の公式ブログ記事「A second spring of cleaning 」で、Google Readerを2013年7月1日に終了すると案内している。公式ブログでは、熱心なユーザーはいたものの、利用が減少していたことが理由として説明されていた。 Google Readerを使っていたわけではないが、そんな私でも記憶しているほど当時は驚きのニュースだった。 RSSを読むための代表的なツールの一つが終了となったことで、一般ユーザーの視界からRSSは急速に消えていったように見える。その後はSNSのタイムライン、ニュースアプリ、レコメンド、今ならAIによる要約やおすすめが、情報を受け取る入口になった。 だから、Google Readerが終わったことと、RSSという仕組みが終わったことは別の話である。 きっかけは海外ニュースをCLIで眺めるツールだった 今回作ろうとしたのは、海外ニュースの見出しをCLIでざっと確認するための小さなツールだった。 リポジトリはこちら。 aragig/shell-toolbox の news-topics 実行すると、複数の海外ニュースサイトから見出しを集めて、ターミナルに一覧表示してくれる。 以下は news コマンドを実行した出力イメージだ。 海外ニュースの見出しをnewsコマンドで表示しているターミナル画面 % news News Topics 12 items | balanced by source cap (2/source) 01. 原油価格が2022年以来の最高値に急騰 [BBC] 2026-04-30 06:55 UTC EN Oil jumps to highest price since 2022 URL [https://www.bbc.com/...](https://www.bbc.com/) 02. ジェット燃料価格の高騰が山火事の消火費用を押し上げている [NPR] 2026-04-30 07:00 UTC EN How rising jet fuel prices are driving up the cost of fighting wildfires URL [https://www.npr.org/...](https://www.npr.org/) BBC / Reuters / NPR / DW / France 24 / Al Jazeera など、複数のニュースサイトから取得する。ソースごとの上限とラウンドロビンでひとつのサイトに偏らないように表示している。 ...

せっかくの大型連休、ゴールデンウィークだというのに雨が続くらしい。 釣りへ出かける気分にもなれない。というより最近はCodexの衝撃とともに、Codexへの指示とレビューに時間を取られまくって消耗し切っている。 もはや私はAIの奴隷に成り下がっているのではないか。 AIが人間社会を楽にしてくれるなんて嘘っぱちじゃないか。人間作業だったら数週間かかるものを一瞬でAIが生成してくれるからといって、人間側はまったく楽にならないのだ。 なぜなら、AIの生成物のレビューに時間がかかる。イメージと違う成果物が出てきたら、当然、自分ではすぐ直せないほど高度なものなので、指示書を書き直して再度依頼する。そんなことを高速で繰り返すものだから、こちらは休みなく働かされ続ける。 少しでも時間にゆとりが出ようものなら、Codexの /status を見て「課金プランを使い切っていないともったいない」という感情が働き、次の指示を考えなければならない。ターミナルだって4窓をCodexに使い、各窓をさらに左右に分割し、人間側が操作できるCLIをなんとか確保している。 きっと私が間違っているのだろうが、最近はそんな日々を送っていたため、だいぶ病んでいる。 現実逃避すべくマイクラを再開したのは自然な流れだろう。 Note ただ、この状態はその後少しだけましになった。手元のMacに張り付いてCodexの様子を見続けるのではなく、さくらのサーバー上にリポジトリをcloneして、Codexに記事リライトを定期実行させる仕組み を作ったからだ。結局AIに仕事を増やされている気もするが、人間がずっとターミナルを監視し続ける時間は少し減った。 久しぶりに一から始めるマイクラ 久しぶりにMinecraftを一から始めた。雨の連休、釣りに行けない気持ちを抱えたまま、仮想世界の砂浜へ降り立つ。 画面を見ていると、これは小田原サーフだろうか、などと勝手に脳内補正が始まる。現実の海へ行けないなら、ブロックの海辺でよいではないか。 ただ、ゲームを始めてすぐ、マイクラそのものよりも「CodexにModをインストールさせてみよう」という気持ちが勝ってしまった。ここがもう病の深いところである。 以前にも手作業でModを入れたことはあったのだが、仕組みをちゃんと理解していないせいか、とても面倒な印象が残っていた。手動ではやりたくない。こういった作業こそCodexに任せるのが正解だろう。 そこで思い出したのが、座標を常に画面上へ表示したいという話だった。 デフォルトでもF3のデバッグ画面を開けば座標は確認できる。ただ、情報量が多すぎて見づらいし、普段のプレイ中にずっと出しておくには少し邪魔だ。必要なのは、座標だけを小さく常時表示してくれる仕組みである。 MiniHUDを見つける 調べてみると、まさに欲しかったものとして MiniHUD があった。 MiniHUDは、いわば小さなF3画面のように、座標などの情報を選んで表示できるクライアント側Modである。Modrinthの説明でも、MiniHUDは「mini F3」的なHUDや各種オーバーレイを提供するクライアントサイドModとして紹介されている。 また、MiniHUDを使うには共通ライブラリである MaLiLib も必要になる。MaLiLibは、設定画面、ホットキー、GUIまわりなど、masa氏系Modで共通利用される部品をまとめたライブラリという位置づけらしい。 こういう依存関係を自分で追いかけるのが面倒だったので、すぐにMinecraft用のプライベートリポジトリを作り、git clone で取り込み、Fork、IntelliJ IDEA、Codexあたりの初期化を済ませた。 GitHub Issuesには、次のような指示を追加した。 codex --search exec --full-auto で以下タスクを順番に自動で進めてください。 --- MiniHUDをインストールして、座標を表示できるようにしてください。 この実装を始める前に、まずは実行計画を立てて下さい。 それをTODOリストとしてMarkdownファイルに落とし込んでください。 このIssueのURLをCodexへ貼り付けて作業開始。数分でMod導入まで進んだ。 このスピード感は確かにすごい。人間が公式ページを読み、依存関係を確認し、バージョンを合わせ、ダウンロード先を探し、配置先を調べる。その一連の調査と作業を、Codexはかなりの速度で進めてくれる。 ただし、速いからといって楽になるとは限らない。ここから人間は、何が入ったのか、どこへ置かれたのか、バージョンは合っているのか、起動して本当に動くのかを確認し続けることになる。 今度はModの表示を変えたくなる 座標が表示できるようになると、さらに余計なことを思いつく。 MiniHUDの表示で WEST や EAST と出ている部分を、「西」「東」のように日本語化できないだろうか。 ただの表示文字列を変えるだけなら簡単そうに見える。だが、Modは普通のアプリではなく、Minecraft本体のバージョン、Modローダー、依存Mod、マッピング、ビルド設定が密接に絡む。ここを理解しないまま触ると、急に難しくなる。 調べるとMiniHUDはオープンソースだった。そこで速攻でforkして、ソースコードをcloneし、IntelliJ IDEAで開いて、表示文字列らしき箇所を変更してみた。 ところが結果として、この方法はうまくいかなかった。 ソースコードを直してもダメだった理由 今回つまずいたポイントは、ソースコードを直すこと自体ではなく、ビルドしたModが自分のMinecraft環境に合っていなかったことだった。 MinecraftのModは、単に「MiniHUDのソースをビルドすれば動く」というものではない。 Minecraft本体のバージョン Fabric、Forge、LiteLoader、OrnitheなどのModローダー MaLiLibなど依存Modのバージョン そのブランチが想定しているマッピングやビルド設定 これらが揃って初めて、入れ替え可能なJARになる。 ...

AIコーディングエージェントに複数の作業を同時に任せたい場面があります。 たとえば、片方ではUIを直し、もう片方ではテストを直す。あるいは、A案とB案を別々に試す。こういうとき、同じ作業ディレクトリで同時に編集させると、未コミット変更やブランチ切り替え、同じファイルの編集が絡んでかなり危なっかしくなります。 そこで使えるのが git worktree です。 この記事では、1つのローカルリポジトリから複数の作業ディレクトリを作り、feature/new-feature-a と feature/new-feature-b を別々に進める流れを、実際のコマンドと結果で確認します。 git worktree とは git worktree は、1つのGitリポジトリに複数の作業ディレクトリを紐づける機能です。 普通は1つのリポジトリに1つの作業ディレクトリがあり、その中で git switch や git checkout を使ってブランチを切り替えます。 一方、git worktree を使うと、ブランチごとに作業ディレクトリそのものを分けられます。 /tmp/worktree-demo は main /tmp/worktree-demo-a は feature/new-feature-a /tmp/worktree-demo-b は feature/new-feature-b というように、別々の場所で別々のブランチを同時に開けます。 git checkout との違い git checkout や git switch は、今いる作業ディレクトリの中身を別ブランチへ切り替える操作です。 作業途中の変更があると、切り替え時に止められたり、stashやコミットが必要になったりします。 git worktree は、ブランチを切り替えるのではなく、作業ディレクトリを増やします。なので、main の作業場所を残したまま、A用、B用の作業場所を別に用意できます。 AIエージェントに並列で頼む場合は、この差がかなり大きいです。 検証用リポジトリを作る 今回はブログ本体のリポジトリではなく、/tmp に捨てリポジトリを作って試します。 cd /tmp mkdir worktree-demo cd worktree-demo git init -b main printf '# worktree demo\n' > README.md git add README.md git -c user.name='Demo User' -c user.email='[email protected]' commit -m 'initial commit' ここまでで main ブランチに最初のコミットが1つある状態になります。 ...