こってり｜AIで業務自動化

本業はWEBデザイナー、今年から会社の業務をAIで自動化してる人。血液はとんこつ、ゲームは癒し、悩みの種は手のかかるAI。自動化の相談、気軽にどうぞ

[こってり｜AIで業務自動化 @kotteri_ai]

■ 補足
投稿で紹介されているのは、つなぐ手順と記録の残し方まで。RTKの入手先と導入方法は書かれていない。
⚠️ 削減量の実測値は示されておらず、-gで設定がどこまで効くかも不明。

■ 出典
https://t.co/mFkPspGBPu

[火山哥🕊️ @huoshan007]

兄弟们，Codex最能烧Token的，真不一定是写代码。
是跑一次测试，几百行日志全往上下文里塞。
RTK装好后先跑：
rtk init -g --codex
重开Codex，再丢一句：
“以后测试、Git和搜索命令优先走RTK；失败必须保留完整错误。跑完用rtk gain把Input、Output、Saved写进RTK记录.md并打开。”
跳出来Hook registered，再看到那三个数字，现在直接OK了。

[こってり｜AIで業務自動化 @kotteri_ai]

【解説】ある投稿者がXに動画つきで書いたところによると、Codexでトークンを一番使うのはコードを書く作業とは限らない。テストを1回走らせ、数百行のログをそのまま文脈に詰め込む場面だという。対策として、RTKというツールをCodexにつなぐ手順を紹介している。

まず、Codexがログをどう扱うか。Codexは修正の途中でテストやgit diff、検索のコマンドを自分で実行し、その出力を読んで次の手を決める。読んだ出力は会話の一部として文脈に残るので、テスト1回分のログも、その後のやり取りにずっと付いて回る。

ログのうち修正に効くのは、落ちた箇所の数行くらいだ。残りは、通ったテストの名前や毎回同じ形で出る行が占める。それでも文脈の枠とトークンは、全行ぶん減っていく。

RTKは、この出力をCodexに渡す前に短くするツールだ。投稿の手順はこう。RTKを入れてrtk init -g --codexを実行し、「Hook registered」と表示されたらCodexを開き直す。最後に、テスト・Git・検索のコマンドをRTK経由で実行するよう、Codexにプロンプトを1つ渡す。

・つなぐコマンドはrtk init -g --codex
・設定後はCodexの開き直しが必要
・rtk gainでInput、Output、Savedの3つの数字を表示
・その数字をCodexに記録用のMarkdownファイルへ書き出させる

何が変わるかというと、減った量を見て判断できるようになる。rtk gainの数字がファイルに残るので、どの作業でどれだけ削れたかを後から見比べられる。投稿者は、実行するとすぐ3つの数字が出て、そのまま使えたと書いている。

落とし穴もある。1つ目は、RTKが何者で、どこから入手するのかが投稿に書かれていないこと。削減量の実際の数字も示されていない。

2つ目は、エラーの手がかりが減るおそれ。投稿者自身、プロンプトに「失敗したときは完全なエラーを残すこと」という条件を入れている。出力を短くしすぎると原因を追う行まで消える、という懸念があるからだと読める。ただし、これはこちらの推測だ。

3つ目は-gの意味。全体の設定に効くように見えるが、どこまで影響するかは投稿からは分からない。

Codexにテストを何度も回させている人は、RTK経由のプロンプトに「失敗したときは完全なエラーを残す」の一文を必ず足しておくといい。

↓詳細

[こってり｜AIで業務自動化 @kotteri_ai]

@huoshan007 ■ 補足
投稿は中国語で、プロンプトの全文が本文に載っている。
⚠️「OpenAIのエンジニアチームが今週公開した」は投稿者の説明で、元の資料は本文から辿れない

■ 出典
https://t.co/FGzKyRcUc2

[火山哥🕊️ @huoshan007]

兄弟们，Codex清理旧代码，最怕它看着没人引用就一刀删了。

OpenAI工程团队这周公开的玩法，有个顺序很对：先找证据，再动手。

直接丢：
“先别删代码。只找一处疑似废弃功能，查引用、测试、Git历史和能拿到的运行证据；拿不到就写明。把删除证据和保留风险整理成清理候选.md并打开，等我确认后再动。”

候选文件跳出来就OK了。

代码旧不旧不重要，证明它真没用了，才有资格删。

[こってり｜AIで業務自動化 @kotteri_ai]

中国語圏のXユーザー@huoshan007が、Codexに古いコードを片付けさせるときのプロンプトを紹介した。いきなり消させない。証拠を集めてメモにまとめさせ、人が確認してから削除に進ませる組み方だ。

長く育ったリポジトリには、もう使われていないように見える関数や設定が残っている。片付けたいんだけど、本当に使われていないかを確かめるのが重い。エディタで検索して呼び出し元が見つからなくても、設定ファイルから名前で呼ばれていたり、外部のジョブが叩いていたりすることがある。

ここでCodexに「使っていないコードを消して」と頼むと、検索で呼び出し元が見つからなかった時点で消してしまうことがある。手元のテストは通るのに、本番で月に1回だけ動く処理が消えていた、ということが起こりうる。

投稿のプロンプトが削除の前に挟むのは、この段階だ。

・使われていなさそうな機能を1か所だけ選ばせる
・呼び出し元、テスト、Gitの履歴、実行時のログを調べさせる
・証拠が取れなかった項目は、取れなかったと書かせる
・消す根拠と残すリスクを候補メモにまとめて開かせる

メモのファイル名は「清理候选.md」。中国語で「片付け候補」という意味だ。人はこのメモを読んでから、消すかどうかを決める。

大事なのは3つ目の行。取れなかった証拠まで書かせておけば、メモを読む人は、どこまで調べてどこが空白なのかがすぐ分かる。AIが「使われていません」と言い切った一文だけを渡されるより、判断の材料がずっと多い。

投稿者は、コードが古いかどうかは関係ないと書いている。消してよいのは、本当に使われていないと示せたものだけ。消す理由を「古いから」から「使われていない証拠があるから」に置き換えるプロンプトになっている。

ただ、この投稿だけでは確かめられないこともある。投稿者はOpenAIのエンジニアチームが今週公開したやり方だと書いているが、元の資料へのリンクは本文にない。投稿は候補メモが出てくれば成功としている。それでも、メモに書かれた証拠が正しいかは結局人が確かめることになる。

実行時のログが手に入らない環境では、呼び出し元とGitの履歴だけで判断するしかない。名前の文字列から動的に呼ばれるコードは、そこで見落とされうる。1回に扱うのは1か所だけなので、大きな片付けには時間もかかる。

次にCodexへ片付けを頼むときは、プロンプトの頭に「消す前に、集めた証拠と取れなかった証拠をメモにまとめて」と1行足すだけでも、この形を真似できる。

↓詳細

[こってり｜AIで業務自動化 @kotteri_ai]

■ 補足
環境変数で外せるのは注記だけで、ファイル名での拒否は権限スキップを付けても残る。測定はモックAPIで行っており、実モデルの振る舞いは含まない。
⚠️ Bashで書けば通るが、Anthropicがこの名前を止めている意図は不明

■ 出典
https://t.co/WvZoHV0YBi

[こってり｜AIで業務自動化 @kotteri_ai]

Claude Codeのサブエージェントにreport.mdを書かせると失敗する件を、仕組みを2つに分けて測った検証記事がnoteに出ていた。測定は2026-10-17で、2.1.90から2.1.302までの8バージョンを対象にしている。

まず前提から。Claude Codeでは、メインのセッションからサブエージェントを呼んで作業を分担させられる。調べた結果をサブエージェントにファイルで書き出させ、メインがそれを読む。よくある組み方だ。

ところが、サブエージェントにREPORT.mdやSUMMARY.mdをWriteで書かせると、エラーが返ってくることがある。筆者は、モデルが断っているのか、Claude Code本体が止めているのかを切り分けた。実際のモデルは呼ばず、台本どおりに応答するモックAPIにつないで、CLIの挙動だけを見ている。

止めている仕組みは2つあった。

1つ目はシステムプロンプトの注記だ。「レポートの.mdは書かず、最後のメッセージで返せ」という英文が入っている。入るのは2.1.128以降のサブエージェントだけ。メインのセッションと2.1.126以前には入っていない。環境変数CLAUDE_CODE_REMOVE_PROMPT_STRINGSで外せる。

2つ目はWriteツール側の検証だ。ファイル名が次の正規表現に当たると、is_errorで弾かれる。

/^(REPORT|SUMMARY|FINDINGS|ANALYSIS).*\.md$/i

こちらは注記を外しても残る。--dangerously-skip-permissionsを付けても、エージェント定義のtoolsにWriteを明示しても消えない。一方、メインのセッションでは同じ名前のWriteが成功した。

判定に使われるのは、ファイル名の先頭の語だけだ。

・reports.md、summary_2026.mdは拒否
・my-report.md、01-SUMMARY.mdは通る
・report/notes.mdのようにフォルダ名なら通る
・Bash経由で書けば拒否されない

これで原因の探し方が変わる。プロンプトで「ファイルに書いていい」と伝えても、2つ目の仕組みは消えない。サブエージェントに渡しているファイル名を直すほうが早い。

限界もある。測定はLinuxのDocker内で、非対話モードで各条件を1回ずつ試しただけだ。2.1.126以前の拒否はサーバー側のフラグで決まり、フラグがオンの状態は測っていない。測ったのはCLIの仕組みだけで、モデル自身が断ったり別の名前で書いたりする振る舞いは含まれない。記事の本文も途中で切れている。

サブエージェントに書かせるファイルの名前を、REPORTやSUMMARYで始まらない形にしておけば、この拒否には当たらない。

↓詳細

[こってり｜AIで業務自動化 @kotteri_ai]

■ 補足
告知はリンク付きの短い投稿と動画だけ。
⚠️対応プラン、実行回数の上限、エージェントに許す操作の範囲は書かれていない。ボタンを押せる人なら誰でも起動できるので、権限は先に見直しておきたい。

■ 出典
https://t.co/DemoA6m5mN

[Notion @NotionHQ]

New: Your buttons just got a brain 🧠

Button automations can now message your agents. Add a prompt to a button, and anyone on your team can trigger a workflow with a click.

[こってり｜AIで業務自動化 @kotteri_ai]

【速報】NotionがNotion内のエージェントに、ボタンの自動化からメッセージを送れるようにした。ボタンにプロンプトを書いておけば、チームの誰でもワンクリックでワークフローを動かせる。

これまでは無理だった。ボタンの自動化からエージェントにメッセージを送る手段がなく、エージェントに作業を頼むたびに誰かがプロンプトを打ち込む必要があった。

・ボタンの自動化に、エージェントへのメッセージ送信が加わった
・送るプロンプトはボタン側に書いておける
・ボタンを押すと、その場でエージェントの処理が始まる
・誰が押しても、同じプロンプトで同じ手順が動く

毎週同じ指示をエージェントに打ち込んでいるなら、その文面はそのままボタンに書いて置いておける。

↓詳細

[こってり｜AIで業務自動化 @kotteri_ai]

■ 補足
比べたのは、Claudeを945回実行した結果。
⚠️作業内容・試行回数・削減率は投稿本文に無く、詳細があるとみられるリンク先は未確認。答えの質への影響も評価されていない。

■ 出典
https://t.co/Jw6oWGmMTK

[Dan McAteer @daniel_mac8]

A Claude Coder ran Claude 945 times to measure what practices save on tokens vs. which do not.

Most useful:

- /clear
- /compact
- Move instructions from CLAUDE.md to a skill

Least useful:

- High effort (vs. Medium)
- Haiku 5.5 (vs. Sonnet 5.5)
- Unused rules

[こってり｜AIで業務自動化 @kotteri_ai]

Claudeを945回実行して、Claude Codeでトークンを減らす方法のどれが効いて、どれが効かないかを比べた結果がXで共有された。効果が大きかったのは/clear、/compact、CLAUDE.mdの指示をスキルに移すことの3つ。

まず前提から。Claude Codeは、こちらが1回話しかけるたびに、それまでの会話をまるごとモデルに送り直している。そのため、同じ一言でも1往復目より10往復目のほうがトークンを多く使う。読ませたファイルの中身やコマンドの出力も会話の一部になる。消さない限り、毎回載ったままだ。

CLAUDE.mdも同じ。セッションを始めると全文が読み込まれて会話の頭にずっと載り続けるので、ルールを書き足すほど、そのルールと関係ない作業の間もその分を払うことになる。

スキルは読み込み方が違う。普段載っているのは名前と短い説明だけ。本文は必要になったときに初めて読まれる。

この前提を置くと、結果の順位の理由が見えてくる。

・効果大: /clear、/compact、CLAUDE.mdの指示をスキルへ移す
・効果小: effortをMediumからHighに変える
・効果小: Sonnet 5.5の代わりにHaiku 5.5を使う
・効果小: 使っていないルールへの対策

効果が大きかった3つは、どれも毎回送り直す量そのものを減らす操作だ。/clearは会話を空にする。/compactは会話を要約に縮める。スキルへの移行は、いつも載っている指示を、必要なときだけ読まれる形に変える。

一方、モデルを替えても、送っている会話の量は変わらない。effortの切り替えも考える量の調整で、積み上がった会話には手をつけない。節約するなら、モデル選びより先に送る量を見直す。結果はそう読める。

ただし、投稿に載っているのは結果の一覧だけだ。どんな作業で測ったのか、1つの方法を何回ずつ試したのかは書かれていない。何%減ったのかも分からない。「効果が小さい」は節約になりにくいという意味で、答えの質が落ちるかどうかは評価されていない。Haiku 5.5よりSonnet 5.5のほうが節約になる理由も、本文には説明がない。

CLAUDE.mdが長くなってきたら、毎回は使わない指示から1つずつスキルに切り出していく。

↓詳細

[こってり｜AIで業務自動化 @kotteri_ai]

@daniel_mac8 ■ 補足
元のプロンプトはAnthropicのFelix Riesebergが共有したもの。スキルにまとめて配布しているのは@daniel_mac8で、入手リンクは元投稿の最初のリプライにある。
⚠️使う前と後で出力を比べた数字はまだ出ていない

■ 出典
https://t.co/BDC26t6sYg

[Dan McAteer @daniel_mac8]

I present to you: /be-ambitious

Anthropic Lead Engineer @felixrieseberg shared an amazing prompt to make agents more *ambitious*.

1) Say what a top professional in this field would do
2) Name the rawest material they would start from
3) Name the specific methods and tools they'd use
4) Say what would prove the result is right

Turned it into a skill: '/be-ambitious'.

Install it for free at the link in first reply.

[こってり｜AIで業務自動化 @kotteri_ai]

AnthropicのエンジニアFelix Riesebergが共有した「エージェントをもっと野心的にする」プロンプトを、@daniel_mac8が/be-ambitiousというスキルにまとめて無料で公開した。中身は4段階の問いかけだ。

まず前提から。エージェントに作業を頼むと、指示の文面を満たしたところで止まった出力が返ってきやすい。「調べて」と頼めば、検索で出てきた記事の要約が返ってくる。「グラフにして」と頼めば、手元のデータでそれらしい図ができる。頼んだことはやっている。ただ、その分野の専門家ならまず確かめる点が抜けていることがある。

原因の1つは、依頼文に「どこまでやれば十分か」の基準が書かれていないことだ。基準がなければ、エージェントは文面どおりに作業を終えた時点で完了と判断する。作業に入る前にその基準をエージェント自身に書き出させるのが、このプロンプトだ。

問いは次の4つで、答える順番もこのとおり。

・その分野のトップのプロなら何をするか
・そのプロが出発点にする、一番生の素材は何か
・そのプロが使う具体的な手法と道具は何か
・何があれば結果が正しいと証明できるか

1つ目で目指す水準を引き上げる。2つ目では、まとめ記事のような又聞きの情報ではなく、元のデータや原文から始めさせる。3つ目で手順を具体的にし、4つ目で「何が揃えば完了か」を先に決める。

効いてくるのは4つ目だ。市場規模を調べる作業なら、記事に載っている数字を拾って終わりにはならない。統計の元の表まで遡り、どの表のどの値かを示すところまでが完了の条件になる。最後に「できました」とだけ返してくる出力を、作業の前に塞いでおくための問いだ。

今回変わったのは形だけで、文章で共有されていたプロンプトがスラッシュコマンドで呼べるスキルになった。依頼のたびに同じ文章を貼り直す手間がなくなる。

限界もはっきりしている。このプロンプトを使った場合と使わない場合で、出力がどう変わったかの比較や数字は示されていない。スキルの入手リンクは投稿本文になく、最初のリプライにある。中身が本文の4段階と同じかどうかは、本文からは確認できない。第三者が配布しているスキルなので、入れる前に中身を読む必要がある。それと、これは投稿に書かれていない推測だが、野心的にさせた分だけ作業の範囲や時間が膨らむことはありうる。

4段階の問いは投稿本文に全文が載っているので、スキルを入れなくても、次の依頼文の頭に貼るだけで試せる。

↓詳細

[こってり｜AIで業務自動化 @kotteri_ai]

■ 補足
ワークフローの定義はリンク先にあるとみられるが、投稿本文からは未確認。
⚠️画像の説明と生成に使うAIサービスの接続設定が別に要るとみられる。モデル名と費用の記載はなし。

■ 出典
https://t.co/60H704iee1

[n8n.io @n8n_io]

Need product photos but don’t have a studio?
Upload 3 reference photos to this n8n workflow. AI describes them, writes the prompt, and generates a new product image for you. Would you use AI-generated shots for your listings? 👀 https://t.co/ghJVv7pJyl

[こってり｜AIで業務自動化 @kotteri_ai]

n8nが公式アカウントで、参考の商品写真3枚から新しい商品画像を作るワークフローを紹介した。AIが写真の中身を文章にし、その文章をもとに画像生成のプロンプトを書いて、新しい画像を出す流れだ。

まず前提から。ネットショップの出品ページに欠かせないのが商品写真。きれいに撮るには照明や背景を整えた撮影スペースが必要で、個人や小さな店ではそこが一番の手間になる。

画像生成AIに頼めば済みそうに見えるけど、ここにも壁がある。「この商品の写真を作って」と頼むだけでは、AIは手元の商品を知らない。色や形、素材を言葉で細かく指示しないと、別物の画像が出てくる。そのプロンプトを商品ごとに自分で書くのが、また重い。

n8nが見せているのは、このプロンプトを書く工程ごとAIに任せる組み方だ。

・参考になる商品写真を3枚アップロード
・AIが写真を見て、商品を説明する文章を作成
・その説明をもとに、AIが画像生成用のプロンプトを作成
・プロンプトから新しい商品画像を生成

要は2段目と3段目。写真を言葉に直す役と、言葉をプロンプトに組み直す役を分けているので、人が商品の特徴を書き出す作業がまるごと消える。

人の手に残るのは、参考写真を3枚撮って渡すことだけ。撮影スタジオが無くても、手持ちの写真から出品用の画像を作れる、という使い方の提案になっている。

一方で、分からないことも多い。投稿は短い紹介文と動画だけで、どのAIモデルを使っているのか、1枚あたりいくらかかるのかは書かれていない。生成した画像がどこまで実物に忠実なのかも不明だ。

出品に使うなら、ここが一番の落とし穴になる。参考写真から作り直した画像なので、色味や細部が実物とずれることがありうる。届いた商品が写真と違えば、買った人は誤解したと感じる。

n8n自身も投稿の最後で「AI生成の写真を出品に使いますか？」と読者に問いかけている。効果を示した発表ではなく、使い道を投げかけた投稿として読むのがいい。

手持ちの商品で参考写真を3枚撮って流し、出てきた画像を実物の横に並べてみる。出品に使えるかどうかは、そこで分かる。

↓詳細

[こってり｜AIで業務自動化 @kotteri_ai]

@goan999999 ■ 補足
Superpowersの入手先と導入手順は投稿に書かれていない。プロンプトの例はNext.jsとTailwind CSSでのサイト制作。
⚠️「効率10倍」は投稿者の主張で、測り方も数値も示されていない

■ 出典
https://t.co/gUmLx29Rfm

[govin.eth | G哥 @goan999999]

WTF！Codex 6.1 装上 Superpowers，效率直接提高 10 倍！关键是不用再反复返工

用 Codex 最烦什么？

你让它开发一个功能，它上来就写代码，写了半天才发现需求理解错了，改完又出 Bug，来回折腾，Token 烧了不少，项目还没做完

Superpowers 就是专门解决这个问题的！

我给兄弟们准备了一段实战提示词，复制到 Codex 就能测试（也可以看视频，后半段有演示效果）：

“
开发一个 AI 工具导航网站，参考 Product Hunt 的设计风格，支持 AI 工具分类、搜索、排行榜和收藏功能，使用 Next.js + Tailwind CSS。调用 Superpowers，先用 brainstorming 澄清需求，不要直接写代码；需求确认后，用 writing-plans 拆解任务；再逐步开发，过程中执行自动化测试和代码审查，最后启动网站让我查看实际效果
”

它直接给 Codex 装上了一套完整的软件开发工作流：

1、需求澄清：先问清楚你要什么，不再直接乱写

2、任务规划：复杂项目拆成小任务，按步骤执行

3、多 Agent 协作：子代理分工开发、检查代码

4、自动测试：先写测试，再写代码，减少 Bug

5、代码审查：交付前检查，避免反复返工

你会发现，Codex 不再上来就埋头写代码，而是先确认需求、制定计划，再进入开发流程

Codex 6.1 负责干活，Superpowers 负责让它少返工！

[こってり｜AIで業務自動化 @kotteri_ai]

X投稿者の@goan999999さんが、Codex 6.1にSuperpowersを組み込んで使う方法を紹介した。そのまま貼って試せるプロンプトもついている。

まず前提から。Codexのようなコーディングエージェントに「こういうサイトを作って」と頼むと、すぐにコードを書き始めることが多い。要件を聞き返さずに進むので、取り違えに気づくのは書き終わってから。直すと、今度は別の箇所でバグが出る。投稿者によると、以前のCodexはこの手戻りを繰り返してトークンを使っていたという。

人間のチームなら、書き始める前に段取りを踏む。何を作るのかを確かめ、作業を小さく分け、テストを用意してから書き、渡す前に点検する。投稿では、Superpowersはこの段取りをエージェントに踏ませるものとして紹介されている。

プロンプトの例は、Next.jsとTailwind CSSでAIツール紹介サイトを作らせるもの。中身はこの順番になっている。

・brainstormingで要件をはっきりさせる。ここではまだコードを書かせない
・要件が固まったら、writing-plansで作業を細かく分ける
・テストとコードの点検を挟みながら、少しずつ開発する
・最後にサイトを起動して見せる

変わるのは、コードを書き始めるタイミングだ。要件の確認と作業の分割を先に済ませるので、取り違えはコードになる前に見つかりやすくなる。投稿者の説明では、ほかにも子エージェントでの分担や、テストを先に書く手順が加わる。

ただし、分からないことも多い。投稿者は効率が10倍になったと書いているが、何を測ったのかも、実際の数値も示していない。効果の根拠は添付の動画だけだ。Superpowersをどこから入手して、どう組み込むのかも書かれていない。この投稿だけでは同じ環境を再現できない。

手順が増えるぶん、1件あたりのトークン消費や待ち時間が増える可能性もある。投稿者はそこには触れていない。Codex 6.1という版の名前も、この投稿以外では確認できていない。

Codexに頼むと毎回すぐ書き始めてしまうなら、まずプロンプトの頭に「要件が固まるまでコードは書かない」と1行足すところから試せる。

↓詳細

[こってり｜AIで業務自動化 @kotteri_ai]

■ 補足
公式の告知は2文と動画だけ。キャンバスで何ができるかの詳細は書かれていない。
⚠️共有リンクを誰が開けるか、対象プランと料金は未記載。社内データを載せる前に、公開範囲の設定は自分で確認が要る。

■ 出典
https://t.co/XkGrZnilFw

[Cursor @cursor_ai]

Cloud agents can now build interactive canvases.

Ask for a dashboard or report while the agent works, then share the finished canvas with your team as a link.

[こってり｜AIで業務自動化 @kotteri_ai]

【速報】Cursorのクラウドエージェントが、操作できる画面（インタラクティブなキャンバス）を作れるようになった。作業の途中で頼むと、ダッシュボードやレポートの形で結果を返してくれる。

・対象はCursorのクラウドエージェント
・作業中にダッシュボードやレポートを頼める
・できあがるのは眺めるだけでなく操作できる画面
・できたキャンバスはリンクでチームに共有できる

エージェントの作業結果をスクショで貼って報告しているなら、依頼の最後に「ダッシュボードにして」と一言足せば試せる。

↓詳細

[こってり｜AIで業務自動化 @kotteri_ai]

■ 補足
Node 18以上で動く。CodexとMistral Vibeのセッションも読める。有料なのはキャラクターパックだけ。
⚠️ セッションファイルの形式は非公開で、作者の推定で読んでいる。Claude Codeの更新で読めなくなる可能性がある

■ 出典
https://t.co/iNtqgoZb9w

[こってり｜AIで業務自動化 @kotteri_ai]

Claude Codeのセッションとサブエージェントを、会議通話の画面のように一覧で見せるモニター「Agent Standup」が公開された。MITライセンスの無料ツールで、作者がRedditで紹介している。

まずは前提から。Claude Codeでは、1つのターミナルに1つのセッション。並行して作業させたいときは、ターミナルを複数開いてセッションを増やすことになる。さらに各セッションの中では、サブエージェントが呼び出されて作業を分担する。

数が増えると、どれがまだ作業中で、どれが自分の返事を待っているのかが分からなくなる。タブを1つずつ開いて確かめるしかない。どのサブエージェントがトークンを多く使っているかも、普段の画面からは見えにくい。

Agent Standupは、Claude Codeが手元に書き出しているファイルからこの状況を組み立てる。Claude Codeはセッションのやり取りを~/.claude/projectsの下に記録している。Agent Standupはこのファイルを読むだけだ。フックは仕込まない。モデルも呼ばない。外部にも送らない。

・全セッションを作業中・待機中・入力待ちで表示
・エージェントごとのトークン量を表示
・1分超のコマンド、3分黙ったエージェントに警告
・過去セッションの再生と変更ファイルの要約

表示する場所は選べる。npxで起動するほか、VS CodeとCursorの拡張、デスクトップアプリがある。tmuxやステータスラインに出せる1行表示もある。

これで変わるのは、止まったエージェントに気づくまでの時間だ。3分黙ると警告が出る。入力待ちのまま放置されたセッションを、何十分も後になって見つけることが減る。トークンの偏りも、作業が終わってからではなく作業中に見える。

落とし穴もある。Claude Codeのセッションファイルの形式は公式に文書化されていない。作者は実際の記録から形式を推定して読んでいる。Claude Codeが更新で書き出し方を変えれば、表示が崩れるかもしれない。もう1つ、これは見るための道具だ。エージェントを止めたり、指示を送ったりはできない。

まずはnpx @double_geste/agent-standup --openで、組み込みのデモを眺めるところから。アカウントは要らない。

↓詳細