Claude、高度なツールを自在に使いこなす！
引用元：https://news.ycombinator.com/item?id=46038047
もっとCLIツールを作ろうぜ！そうすればエージェントAIはyourtool --helpで使い方を学べるし、JiraみたいなMCPサーバー経由じゃなく直接jiraってCLIツールを叩けるようになるよ。CLIツールがもっと良くなれば、AIも人間も助かるって話。
CLIツールは確かに素晴らしいアイデアだけど、LLM以前にも価値があったのに、ほとんどのサービスは提供してこなかったよね。Jiraみたいなサービスは、あまりオープンになりたくないからだと思う。今のLLM/MCPブームがあっても、APIが十数年前に流行った後にロックダウンされたのと同じように、MCPツールも結局制限されていくと思うよ。
結局、ツールはロックダウンされるって意見には賛成。デスクトップソフトが出荷されない大きな理由の一つは、古いツールをサポートするコストがとんでもなくかかるからだよ。例えば「なんで＜製品名＞が壊れてるの？」ってチケットが来ても、結局6年前のバージョンを使ってて、3年前に非推奨になってたAPIを叩いてるって判明するのに何回もやり取りが必要だったりする。複数の製品バージョンをサポートするのは本当に大変なんだ。実行可能なツールを追加すると、古くなる問題はさらに大きくなるよ。
もし「何回もやり取りが必要」ってなるなら、そのサポートは価値がないね。アプリケーションのバージョンは、チケットを開くときに最初に収集すべき情報、もしかしたら必須にすべきだよ。
違う製品のバージョンを言われたことない？もちろん相手によるし、3回は最悪のケースを誇張してるけど、昔の職場で「これ、うちの製品ですか？」って確認から始めるサポートリクエストを見たよ。そんな相手からバージョン情報を得るには、正確な手順をメールで説明し、さらに電話で手伝う必要があったりするんだ。Jiraチケットや開発者向けソフトならまだいいけど、CSチームの生の声を聞けば、彼らがいかに基礎的な対応に時間を費やしてるか驚くかもね。
CLIツールって開発者視点だと最初は簡単そうに見えるんだよね。「WebアプリのAPIを使うGoかNodeアプリをサッと書けばいいや」って。でも1〜1.5年後、新機能やAPIの破壊的変更がいくつか入ると、CLIソフトをAPIと同期させるのが大変な大仕事だとわかるんだ。自動更新のインフラも管理しなきゃいけないし、どのバージョンを非推奨にするかの管理も難しい。この問題を解決するためにTerminalwire（https://terminalwire.com）を作ったよ。各企業が独自のCLIと自動更新インフラを作りたがるのは、自社サイトを見るために独自のブラウザを送り出すようなもので、ちょっとおかしいと思うな。
私はClaudeにJiraと連携する小さなCLIツールを書いてもらってて、すごくうまくいってるよ。「cases」で進行中のケースリストを表示したり、「other_changes」でリリース内の特定ラベルのチケットを見たり、「new_release」でJiraやデプロイDBに新しいリリースを作成したりできるんだ。必要な時にツールをオンデマンドで作るサブエージェントみたいなものを想像できるね。Claudeはこういう小さなツールを作るのが本当に得意だよ。
誰もCLIツールを出荷しなかったのは、以前はほとんど誰も使えなかったからだよ。でも今はLLMにコマンドを生成してもらえばいいから、ずっとアクセスしやすくなったよね。
JiraにはMCPサーバーとCLIツール（acli）があるんだ。俺はClaudeのコードをMCPからCLI（スキル付き）に切り替えたんだけど、こっちの方が効率的で速いみたいだよ。
JiraみたいなオンラインサービスのCLIツールは、結局はオープンでドキュメント化されたAPIなんだよね。こういうAPIに対する考え方は、君が言ってるように、当分変わらないだろうね。
LLMは、コンテンツのスクレイピングや代替サービスプロバイダー探し、あるいは独自のソリューション作成にも本当に役立つから、移行する手助けになるよ。
それってエージェントがターミナルで動いてるときしか役に立たないよね。Excelのセルを更新する例があったけど、SharePointのAPIで1つのセルを更新するのだって、APIラウンドトリップで数秒かかるから、実際には結構時間がかかるんだ。最近、個別のAPI呼び出しをやめるために書き直したばっかりだよ。
俺はGitLab CLI（glab）をすごく使ってるんだ。公式のGitLab MCPよりもずっと使いやすいからね。Claude Codeを起動する前にglab auth loginを実行して、CCにglabを使ってGitLab APIと通信させるんだ。MCPを使うと、OAuthのブラウザ起動プロセスとか面倒だし、使えるツールも9～10個に限定されちゃうからね。
「MCPサーバーの95%は役立たず」って動画も見てみて。https://youtu.be/7baGJ1bC9zE?si=ShyLg2mHWwbBW1DSt
要するに、AIアシスタントはすでにコマンドラインツールを使えるんだよ。
俺はまさにこのやり方でコーディングエージェントを使ってるよ。小さいCLIツールを--helpオプション付きで作らせて、./toolsディレクトリに置くんだ。そうすればエージェントに「このツールを使え」って指示できるんだ。初めてプロンプトでtool --helpって言うときは、バッククォートで囲むと良い感じ。めっちゃうまくいくよ。
これ試してみるわ。なんか promising だね。もっと詳しく例を見せてくれない？
もちろん！エージェントはヘルプの“Examples”セクションを冗長な例で埋めがちだから、ツール開発中は手動で手直しが必要だよ。gh-installはfishスクリプト（curlとjqを使用）で、エージェントが作ったものだ。gh-install -hの出力と、asdf、hadolint、ripgrep、fd、delta、batをインストールするプロンプト、そして複数のツールを使う場合のプロンプトも記載しているよ。
Playwright（ウェブページをAPIとして利用）を使ったJSスクリプトでデータをJSON形式で取得し、それをjqで処理させるツールもいくつか持ってるんだ。
これは役に立つわ。ありがとう！
CLIツールはスクリプトと組み合わせることで、もっと速くて再現性の高い体験ができるんだ。
こういう理由で新しいCLIツールが出てくるのって、結構好きなんだよね。例えば、hono cliとかいい感じ！ https://blog.yusu.ke/hono-cli/
JIRAがいい例だね。オンプレミスでデータベースにアクセスできた頃は自動化できてたけど、今はクラウドに閉じ込められててAPIもクソだから、アドオンをもっと売りつけたいんだろうね。もう代替を探してるよ。
うん、俺たちのAIは、まず /help APIを呼んで、どんな操作が可能でどう使うかをミニ化されたドキュメント形式で確認するようになるんじゃないかなって気がするよ。
これってクライアントじゃなくてサーバーで実行されるツールについての話だと思うんだけど。全体的にすごい混乱してるから、間違ってるかもね。
CLIツールには賛成だけど、限界もあるよね。別の会社がMCPサーバーを更新すれば、あなたは楽に新しいツールを手に入れられる。例えばJira CLIツールだと、自分でスキルを書いて最新の状態に保つ必要があるけど、MCPサーバーならほとんどの作業を委任できるからさ。
PATとAPIドキュメントをもらったら、まさにこれ、自分でツールを書くんだよね。Atlassianがやってくれたらもっといいんだけど、期待はしてないよ。
それか、LLMにツールを作らせてエージェントに渡せばよくない？さらに一歩進めると、ツールは完全に一時的なもの、つまりたった1回のチャット会話の間だけ存在するものにできるかもね。
プログラマティックなツール呼び出しってさ、ずっと次のステップだったよね。LLMにとってコードが言語になるのは明らかだから、その言語定義が超重要。でも、ツール検索ってのはいらないと思うな。必要なツールはコンテキストエンジニアリングで十分用意できるし、検索を増やすのは余計なオーバーヘッドだよ。もっとコンパクトなツール定義言語やオブジェクト指向が必要だね。オブジェクトをコンテキストにポンと置けば、型や呼び出せるメソッドを理解してくれるのが理想なんだ。
なんで新しい言語が必要なの？僕が書くエージェントはPython SDKやパッケージにアクセスできるし、カスタム関数も使えるんだ。LLMはコードを自分で組み立てる能力があるんだから、ツールとか擬似RPCみたいな面倒な仕組みは無意味じゃないかな。
ちょっと待って！わざとエコシステムを複雑にして、その解決策としてツールやコンサルティングを売ることで儲けるっていう収益源を無視してるよ！そうすれば、うちの超金持ちテック系兄弟たちは新しいヨットをたくさん買えるのにさ！
僕のVS Codeフォークはみんなを庭に連れてくるんだ。そしたら「君のより良いね」って言うんだ。そうだ、僕のより良いんだよ！
もっとコメントを表示（1）
これ、最近Hacker Newsで読んだコメントの中で一番クリエイティブだね。
新しい言語が必要というより、AIゲーム開発で使われるプリミティブ、例えばビヘイビアツリーとか、コアとなるエージェントループの方が重要なんじゃないかな。
これって、GraphQLがフロントエンドで解決する問題にちょっと似てるよね。クライアントとサーバー間のやり取りを減らして、サーバー側でもっと多くの処理ができるようになるんだ。
最新のMCP仕様（2025-06-18+）で、構造化コンテンツと出力スキーマが導入されたんだ。Smolagentsはこれを使って、ツール出力をオブジェクト（例えばdict）として扱ってるよ。これって、君が考えてたことに近いんじゃないかな？詳細はこのブログ記事を見てね。
https://huggingface.co/blog/llchahn/ai-agents-output-schema
ごちゃごちゃした現状より、.d.tsみたいにするとメンテやテストが楽だね。LLMはコードも書けるから、書き込み権限を与えよう。SQL ServerやgRPCとか何とでも話せるし、ツールも自分で作れる。Jupyterみたいな対話プラットフォームや音声入力もいるね。他のセッションと連携すればもっと効率的。もう自分をコピーできるから、このシステムを“Skynet”って呼んでいいかも。
ビヘイビアツリーのselectとsequenceの強力さに気づいて、なんでこんなに使われてないのか不思議だよ。JavaScriptで不変な契約作るの見てゾッとしたけど、ビヘイビアツリーで書けば、もっと理解しやすく検証も楽だよね。変更範囲を制限できるだけでも大きなメリットだよ。
Rexxみたいな高レベルコマンドを想像してるけど、それだとプログラミング言語とシェルの区別が曖昧になっちゃう。高レベルなのはトークン節約のためだけど、表現力は下がるね。LLMがコマンドじゃなくてファイルを読み書きするPlan 9スタイルも試したい。ユーザーはファイル操作だけ考えればいいから、便利かもね。
俺はこれをMCPサーバーとして作ったよ。他のMCPサーバーにプロキシするみたいに動いて、ツール定義をTypeScriptのアノテーションに変換し、LLMに生成させたTypeScriptを制限VMで動かしてツール呼び出しをするんだ。去年のAppleのホワイトペーパーが元だよ。詳しくはこちら：https://github.com/zbowling/mcpcodeserver
公開メソッドを持つオブジェクトをコンテキストにドロップして型を認識したいとか、Rexxみたいな高レベルコマンドとかの話を聞くと、PowerShellを再発明しようとしてるみたいだね。PowerShellはシェルでありスクリプティング言語。全部自己記述オブジェクトで、シェルでパイプしてメソッドを呼べるんだから、まさにそれだよ。
WebAssemblyランタイムなしで、この“非破壊的なPython SDKのサブセット”って今あるのかな？CELみたいに検証可能なランタイム保証があって、構文がPythonのサブセットになってるやつが欲しいんだけど。
Pythonみたいなシンプルな構文と、それに対応するモデルの学習が必要だね。これはJSONスキーマよりはるかにコンパクトで、o1 (MyClass)みたいにオブジェクトをリストできる。プログラマティックなツール呼び出しと組み合わせれば、コードとの連携も柔軟で最高だよ。AnthropicやOpenAIが早くこれに気づいてほしいね。インライン応答も必須だよ。
ツール探索って、多くのチームが目指してたことを形式化してるね。俺は前まで「ツール呼び出し」って呼んでたんだ。LLMがドメインごとにツールを知ってて、ドメインが言われたらツールが読み込まれるんだ。これはもっと賢そうだね。
LLMにPrologベースのDSLを試してるんだ。HuggingfaceのsmolagentsみたいなCodeActスタイルでさ。DSLで複数のツール（MCPとか内蔵ツール）やLLMプロンプトを連携できる。まだ実験段階だけど、結構楽しいよ。
見てみて: https://github.com/deepclause/deepclause-desktop
ユーモアが否定されたわけじゃないんだよな。誰かがクリエイティブなコメントって言ってたし。俺も鼻で笑っちゃったけど、まあ正直な話ね。
君のインスピレーションだったから、このトピックでのClaudeとの議論の要約があるよ（暗号の部分は除く）。
https://claude.ai/public/artifacts/2b23f156-c9b5-42df-9a83-f…
よく分かってないツールのさらに上に抽象化レイヤーを追加するのって、病気だよ。
めっちゃ同意！俺もこのアイデアを数週間前に実装したんだ。
https://github.com/Orange-County-AI/MCP-DSL
もし君の”yum”が、俺がいるコミュニティの質を下げちゃうなら、まあね…
複雑さはなくならない。ただ別の場所に移動するだけだよ。
AIにプログラミング言語（関数やオブジェクト）を覚えさせるのは、今のMCPのグチャグチャな状態に代わる良い方法だと思うな。
AIアシスタントにはあるパターンがあるって気づき始めたよ。今あるツールで推奨されるやり方が非効率だから、もっと効率的な方法を自分で実装するじゃん？ そしたら2〜3ヶ月後には新しいツールが出てきて、俺の努力が全部無駄になるんだよね。これが最先端を生きる代償ってことかな。
腹立つのは、 hypeだらけで今何が本当に使える方法なのか見えにくいこと。最先端を追うのはやめて、たまにChatGPTを使うくらいだったんだけど、古いコードベースにAIアシスタントを使うアイデアは良いと思って、最近また新しい方法を試したんだ。でもまだグチャグチャで、俺が間違ってるのか、それとも正しい方法がないのか分からない。数週間や数ヶ月で時代遅れになるツールに投資する前に、もう少し待つかな。
これが最先端のコストだよな…。会社のAI Slackチャンネルでは毎週、何をするのがベストか聞かれるけど、答えはいつも『今日時点ではA、B、Cだけど、来週／来月には変わるよ』って感じ。俺はこういうの好きだな。俺たちはこのテクノロジーの最前線にいて、数年後には子供たちに昔はどうだったかって話せるだろうしね。
この時代について語られる話は、どんな好景気と不況のサイクルと同じになると思うよ。熱狂的な進歩感があったせいで、ほんの一握りの人たちがとんでもなく金持ちになって、大多数の人や社会全体はたくさんの時間、お金、尊厳を失うことになるだろうね。
世界の超賢い人たちが24時間体制でこれらに取り組んでる結果だよね。モデル自体が改良されて昔のやり方が不要になったり、性能を絞り出すための賢いハックが、もっと良い公式機能で時代遅れになったりするんだ。
これは賢い人たちがバブルの中で仕事してる結果だね。解決すべき問題も、目指す共通の解決策もなく、『AI』っていう漠然とした方向性と、誰よりも先にそこに着きたいってプレッシャーがあるだけ。みんな最前線で忙しいと思ってるけど、実際にはごく一部の人しかイノベーションしてない。俺たち他のみんなは、毎週『今のAIの問題』に対する新しい解決策を学び直して時間を無駄にしてるだけなんだ。毎日／毎週、『先月の最新解決策だった問題に対する、新たな最新解決策』を読むのはマジで疲れるよ。特にそれが大抵『prompt engineering』とか『software engineering』の言い換えなだけだとね。
『先月の最新解決策だった問題に対する、新たな最新解決策』を毎日／毎週読むのは疲れる』って言うけどさ、今思いつく限りでは、新しい解決策は問題の一部を解決して、その次の新しい解決策は残りの問題の一部を解決する、って感じ。例えば、固定の10個のツールでツールコーリングしてるなら、このブログ記事の内容は必要ない（トークン数最適化には使えるかもだけど）。これは他のプログラミング分野と同じだよ。＜form＞要素で十分なシンプルなフロントエンドなら、フロントエンドフレームワークのトレンドを追う必要ないじゃん？ 同じように、AIトレンドに毎日ついていく必要もないんだ。1年前のAIと簡単なprompt engineeringで十分なプロダクト問題は、まだたくさんあるんだから。
『世界の超賢い人たちが24時間体制でこれらに取り組んでる結果』って言うけどさ。ハハ、心配いらないよ。彼らはすぐにchatbotの中に広告を入れる作業に戻るだろうからね。
Fire and Motionっていう記事だよ。読んでみて。https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
半人前で最先端を追ってるから、問題について考え始めたら2、3日後にはそれを解決する新しいツールが出てきちゃうんだよね。
もっとコメントを表示（2）
なんでツールを全部contextに詰め込む必要があるんだろ？全部のツールを例えばMarkdownファイルに置いといて、subagentが問題を説明したら必要なツールだけを返すってのはダメなの？このツール検索ってそれなの？
ClaudeってCLAUDE.mdに書いてあることほとんど無視するから期待できないんだよね。例えば、特定のテスト実行スクリプトを渡しても、いつも一般的な間違ったコマンドを使っちゃうから、正しいコマンドを思い出させないとダメなんだ。
Geminiでも同じ経験があって、指示を無視するんだよね。たぶんcontext rotだよ。LLMは大量のtoken数を謳ってるけど、たくさん詰め込むほど記憶の信頼性が落ちる。Transformerの内部動作を考えれば納得だね。
俺が言ってるのはそれとは逆なんだ。CLAUDE.mdは常にcontextにロードされるからモデル全体に影響するけど、俺が提案するのはPOTENTIAL_TOOLS.mdだよ。これはcontextにロードされずに、Claudeはその存在を知ってるってファイルね。
そしてClaudeは計画中にsubagentを起動して、このファイルから関連するツールのサブセットを識別させて、それをメインagentに返すんだ。そうすればメインagentのcontextには関連ツールだけが入るってわけ。
Claudeってmavenの-amフラグを忘れがちだし、interpreterが変な動きしないheredoc付きのbashを書けないし、jqで!=演算子を使えないんだよね。Claudeって早期認知症かも。
このご時世に認知症のAIが暴走するなんて、まさに求めてたものだね。
俺も同じ問題があったよ。CLAUDE.mdが忘れられて、そこに書いたベストプラクティスを忘れちゃうんだ。
今はhookを使って、いろんなことを実行させてる。例えばテストの強制とかね。Claude.mdよりもこっちの方がいいみたい。だって変更するたびにhookを実行しなきゃいけないからさ。
Claudeがタスクを「完了」と手渡す前に、チェックリスト項目を満たすようにしたいんだけど、いつも無視されちゃうんだよね。CLAUDE.mdにヘルパースクリプトを書いてるのに、Claudeは半分くらい忘れてるんだ。
「タスクは完全に実装され、エラーもなく、テストもパスしてバグもない！」って言われて、「CLAUDE.mdのrun-devでサーバのビルド/ログ出力は確認した？」って返すと、すぐに正しいコマンドを思い出して問題を修正するんだ。これのせいでagentic coding sessionが歯を食いしばるような作業になっちゃう。
context pollutionを避けるためにsubagentを設計し始めたけど、hooksが欠けてるピースみたいだね。毎回確実に実行されることを保証するには必要だよ。
CLAUDE.mdに全部指示書くより、カスタムSkills使ってみない？僕も使ってるけど、これすごく良いよ！ただ、トークン消費が増えるのが玉にキズかな。
うん、Skillsって時々信頼できるけど、いつもじゃないのがネックだよね。LLMが指示通りに動いてくれないから、僕のアプリには使い物にならないんだ。
あとね、startup|resume|clear|compactで動くセッションフックを追加して、ClaudeにカスタムSkillsを思い出させるといいよ。これで、長いこと使ってもズレなくなるからね。
Skillsのマッチングロジックって厳しいよね。フロントマターで’git’って書いてて、’gitlab’を使ったらSkillがトリガーされるか、ちょっと気になるな。
なんか、重みと戦ってるみたいだね。LLMが期待してることに設定を合わせるには、どうすればいいんだろう？
それがまさにClaude Skillsの役割だよ[0]！このツール検索とは別物に見えるけど、MCPとSkillsは統合に向かってると思うな。
[0] https://code.claude.com/docs/en/skills
Skillがうまく呼ばれなくて困ってる。「X doer」ってSkill作って、「＜file＞を開いてXをして」ってやっても、ほぼ機能しないんだ。「＜file＞を開いてX doer Skillを使ってXをして」って書き直す必要があって、前と手間が変わらないよ。
startup|resume|clear|compactで動くセッションフックを追加して、ClaudeにカスタムSkillsを思い出させるといいよ。
セッションスタートフックってあるの？最近追加されたのなら別だけど、知らないな。小さいプロジェクトばかりだからコンパクトも使わないし。新しいセッションの最初のプロンプトでもSkillsが動かないんだよ。
僕も同じ経験してる！確実にトリガーさせるには、「X skill」って明確に伝える必要があるみたいだね。Claudeに色々なルールがあるから、特定の言葉が必要なんだろうな。
