- Gemini CLIでJetBrains IDEをネイティブに認識できるようにする機能追加の要望
- 現在のCLIは**VS Codeなど特定の環境変数（TERM_PROGRAM）**の値しか許可しておらず、JetBrainsユーザーは機能を有効化するために環境変数を偽装する必要がある
- WindowsとLinuxでプロセス検出に失敗する問題が報告されており、環境変数ベースのIDE検出が必要だと明記されている
- 提案された変更はIDE_DEFINITIONSにJetBrainsシリーズを追加し、
TERMINAL_EMULATOR=JetBrains-JediTerm を認識するロジックを含む
- Gemini CLIのIDE統合の対象範囲を拡張し、JetBrainsユーザー体験を改善するための重要な改善要望
JetBrains IDE検出機能の提案
- Gemini CLIにJetBrains IDE環境の認識機能を追加してほしいというIssueが登録された
- これまでは
TERM_PROGRAM の値が vscode などに限定されており、JetBrains IDEでは機能が自動で有効化されなかった
- これを回避するため、JetBrains向けプラグインのユーザーはVS Codeの環境変数を模倣しなければならなかった
- 提案内容はJetBrains IDEシリーズをIDE_DEFINITIONSに追加し、
TERMINAL_EMULATOR=JetBrains-JediTerm の値を公式サポート環境として認識するよう修正すること
必要性と問題の背景
- WindowsとLinux環境ではプロセス検出機能が正常に動作しない問題がある
- 関連事例はJetBrains Plugin ReviewページやGemini CLIのIssue #9273などで確認できる
- 複数のユーザーフィードバックやメール報告を通じて、環境変数ベースの検出ロジックの必要性が示されている
関連する議論と活動
- この提案は以前のPR #16083に着想を得たもの
2件のコメント
翻訳されたHacker Newsのコメントがいったい何を言っているのか、しばらくの間すっかり戸惑っていたのですが、
リンク先のPRを詳しく見てみたら答えがわかりました。GN+にはちょっと荷が重い話題だったようで、という感じですね（笑）
Hacker Newsの反応
ページの途中に "4609 remaining items" という文言があった
gemini-cli ボット2体が、自分ではない相手側がラベルを追加・削除したと誤認し、互いに修正しようとして無限ループに陥っていた状況だった
このリポジトリには長期的な貢献者が約10人いるが、全員がメール通知を受け取ると仮定すると、1日で 46,000通のメール が送信された計算になる
また、gemini-cli アプリページ を見ると開発者が個人アカウントになっており、公式の Google プロジェクトではないように見える
だとすると、この inference コスト はいったい誰が負担したのかという疑問が湧く
#16723, #16725, #16732, #16734
GitHub のアプリ作成プロセスが現状では個人アカウントでしかできないため、こうした問題が起きている
組織メンバーにアプリ作成権限を付与できるよう改善作業が進められており、6か月以内の優先事項として対応予定だ
課金については、各組織が自分の API キー を GitHub Actions の secrets に入れて使うため、inference コストは各組織が負担する
ボットは自分の名前は知っていたが、その名前がユーザー ID としても表示されうることを理解しておらず、自分自身を認識できなかった
エージェントが世界をどう理解するかという 自己認識モデル は慎重に設計する必要がある
これはボットだけの問題ではなく、人間もよく陥る罠だ
以前、うちの会社に来たばかりの「Salesforce の専門家」が、サポートキューを改善すると言って作ったルールがあった
サポートチームが新しいメールを受け取ると Salesforce でチケットを作成し、チケットが割り当てられると再びメールを送る仕組みだった
結果として 無限通知ループ が発生し、本人がミスを認めなかったため、原因特定にかなり時間がかかった
1時間で何百件ものチケットが生成された
むしろ Excel で管理したほうがマシだと思った
自動返信ルールが互いにかみ合って数千通のメールが積み上がり、最終的にはログインシステムまで麻痺した
6か月間コンピュータ使用禁止を受け、その後は IT 室で私の画面をリアルタイム監視するようになった
1年後にまた問題が起きたときには、IT チームが私の教室まで走ってきて、そのまま連れて行かれたこともある
Salesforce は本当に 怪物みたいなシステム だ
先週も同じリポジトリで、似たような AI ボット同士の自己論争 があった
誰かが「だから RAM が 800ドルもするんだ」と冗談を言っていた
このスクリプトの作者は私だ :-)
2つの GitHub Action ワークフローが衝突した
(1) 特定条件で need-triage ラベルを外すワークフロー
(2) プロジェクト管理者でないユーザーがラベルを外したら再度追加するワークフロー
夜10〜11時に提出して寝たところ、朝には何千件ものメッセージが生成されていた
原因は、(2) で ほかのボットや自動化 も例外扱いにすべきだった点で、気づいてすぐ修正した
幸い大きな被害はなく、最初に見たときは 思わず吹き出した
Gemini-cli[bot] が自分自身と戦いながらラベルを付けたり外したりを 4600回以上繰り返した 事件だ
ついに AI が 役に立つこと をした事例だ
人間が手で 4500回もラベルを付けたり外したりしたと考えると恐ろしい
AGI の実用性が証明されたということだ（半分冗談、半分本気）
ここで本当に AI が関与していたのか気になる
単に2つの自動化ルールが衝突しただけに見える。2015年でも起こりえたバグ のようだ
まだ AGI までは遠い し、実のところ AI 自体もまだまだ先が長い
典型的な CI バグ に LLM の香りが加わった事例だ
うちでも数週間前、カスタム merge queue で似たことがあった
昔 IRC ボットを作ったときも、2番目のステップは「自分自身に返信しないようにする」ことだった
だからこれは CI バグというより 設計ミス に近い
これは PR のように見えるが、実際には issue レポート だ
修正パッチはどこだろうと思ったら、このリポジトリではすべての PR に 紐づく issue を必須としていた
ところが今回は、両者がそもそも関連付けられてすらいなかった
こういうことは遠からず 社会保障給付、がん治療計画、航空物流、ISP のルーティング設定 のような分野でも起きそうだ
これから本当に 興味深い時代 になりそうだ