飛書CLIがオープンソース化、AIエージェント時代に皆がコマンドラインツールを作る理由は？

タイトル: 飛書がCLIをオープンソース化、AI Agent時代に誰もがコマンドラインツールを作る理由

飛書がコマンドラインツール lark-cli をオープンソース化しました。これにより、AI Agentが直接飛書を操作できるようになります：メッセージ送信、カレンダー確認、ドキュメント作成、マルチディメンショナルテーブル作成、メール送信、タスク管理。ユーザーがAIに一言指示するだけで、AI自らが飛書を操作してタスクを完了します。

同様のCLIは他にも多く存在します。3週間前にはGoogleもgwsをオープンソース化し、AI AgentがGoogle Workspaceを操作できるようにしました。2026年、AI Agentへの接続を望むすべてのプロダクトがCLIを開発しています。

CLI（Command Line Interface）とは、コンピュータ上で黒地に白文字のターミナルウィンドウを開き、一行のコマンドを入力してエンターキーを押すと、コンピュータが作業を実行してくれるものです。

例えば、今日のスケジュールを確認したい場合、飛書アプリを開いてカレンダーを探す必要はありません。次の一行を入力するだけです：

lark-cli calendar +agenda

ボタンもアイコンも、派手なインターフェースもありません。CLIはグラフィカルユーザーインターフェース（GUI）より20年以上早く登場しましたが、Windowsの時代には次第に使われなくなりました。しかし、AI Agentの時代に再び注目を集めています。

なぜAI Agent時代に、誰もがCLIを作っているのか

AI Agentが作業を行うには、ツールを操作する能力が必要です。AIに会議室を予約してもらうには、カレンダーシステムにアクセスできなければなりません。顧客データを整理してもらうには、テーブルの読み書きができなければなりません。コードをデプロイしてもらうには、デプロイコマンドを実行できなければなりません。

AIが呼び出すためのインターフェースが必要です。APIでもこの役割は果たせますが、CLIにはAPIにはない利点があります。それは、CLIが自己記述的であることです。AIが未知のCLIに出会ったら、--helpと入力するだけで使い方がわかります。

さらに、CLIは本質的にテキストによる対話です。入力も出力も文字列です。AIが最も得意とするのは文字列の処理です。逆に、AIにGUIを操作させるのは迂遠です。スクリーンショットを撮り、視覚モデルでボタンの位置を認識させ、マウスクリックをシミュレートする必要があります。一行のコマンドで済むことを四つのステップに分解し、各ステップでエラーが発生する可能性があります。AIにとって、CLIは自然な操作インターフェースなのです。

AI Agentに外部サービスを操作させる現在の主流の方法は、主に三つあります：MCP（Model Context Protocol）、CLI、スキル（Skills）。これら三つは互いに置き換わる関係ではなく、それぞれ異なる役割を担っています。

• CLIは、実際に作業を行う「手」です。 インストール後、ターミナル内でコマンドを実行でき、カレンダー確認、メッセージ送信、テーブル作成など、すべてCLIが実行します。
• MCPもAIに外部サービスを操作させますが、方法が異なります。 MCPは事前にツールのリストをAIに登録し、AIはいつでもそれを呼び出せます。しかし、このリスト自体は常にコンテキストウィンドウ（AIの「作業記憶」と考えられ、容量は限られています）に残ります。AIが一時的にそのツールを使っていなくても、その説明が容量を占有してしまうのです。一方、CLIは、AIが必要なときに自分でターミナルにコマンドを入力し、使い終われば立ち去るため、コンテキストを占有しません。
• もう一つの違いは組み合わせ能力です。CLIはパイプライン（|）やパラメータを使って、事前に設定されていない操作を組み立てることができます。例えば：

lark-cli calendar agenda --next-week | grep "張三" | wc -l

この一行のコマンドで、来週に張三との会議がいくつあるかを調べられます。MCPの各機能は事前に登録する必要があり、同じ効果を実現するには、新しいツールを個別に定義しなければなりません。

ただし、MCPには独自の適したシナリオがあります。コマンドラインをサポートしていない環境（例えばCursorやClaudeデスクトップ版）では、MCPが唯一の選択肢となります。両者にはそれぞれ長所があります：ターミナルにアクセスできる環境ではCLIがより軽量で柔軟、ターミナルにアクセスできない環境ではMCPに依存することになります。

• スキルは、Agentのための「説明書」です。 スキル自体は作業をしませんが、Agentに対して、このCLIにはどのようなコマンドがあるか、どのシナリオでどのパラメータを使うべきか、エラーが発生したらどう対処するかを伝えます。スキルファイルがなくてもAgentはCLIを使えますが、その場合は--helpを頼りにすることになります。

簡単に言えば：CLIは「手」、MCPは「別の手」、スキルは「筋肉記憶」です。飛書が今回オープンソース化したプロジェクトは、CLIとスキルを一緒に提供しています。

AIのために良いCLIを書く方法

適当にコマンドラインツールを書いただけでは、AIがスムーズに使えるわけではありません。もし自社のプロダクト向けにAI向けのCLIを作りたいなら、飛書の設計にはいくつか参考になる点があります。

1. helpテキストは最も重要なドキュメントです。 AIが知らないCLIに出会ったら、最初に実行するのは--helpです。このテキストはAIが最初に読む説明書です。コマンドの使い方、パラメータの意味、具体例を明確に記載すべきです。例えば：

Usage: myctl deploy [flags]

1. dry-run（ドライラン）をサポートすること。これはAIのための安全網です。 AIは自ら判断を下しますが、時にはユーザーの意図を誤解したり、操作すべきでないデータにマッチしたりすることがあります。dry-runは「プレビュー」メカニズムに相当します。

例：AIに飛書のマルチディメンショナルテーブルから先月の期限切れデータを削除するよう依頼します。直接実行すると、間違って削除したら元に戻せません。--dry-runを追加すると、AIは実際に削除する前に、どのデータが削除されるかをリストアップして確認を求めてきます。

1. エラーメッセージは、次の操作を導けるものでなければなりません。 人間がPermission denied（権限拒否）を見たら、権限がないとわかりますが、AIはどうすれば権限を得られるかわかりません。良いエラーメッセージは、次のステップを提案すべきです。例えば：

Permission denied

lark-cli auth login --scope "calendar:calendar:readonly"

1. 構造化データを返し、出力量を適切に制御すること。 飛書CLIはjson、csv、tableなど複数の出力形式をサポートしています。人間にとってはtableの方が見やすいですが、AI Agentにとってはjsonの方が信頼性が高いです。良いCLIは単に実行できるだけでなく、他のツールが処理しやすいものでなければなりません。同時に出力量の制御も重要です。AIのコンテキストウィンドウは限られているため、もしコマンドが一万行のログを返したら、コンテキストは圧迫されてしまいます。飛書CLIはページングパラメータ（--page-limit）を提供し、AIが必要なデータ量を制御できるようにしています。

CLIを設計する人でも使う人でも、次の点を覚えておいてください：Agentに作業をさせる前に、まずdry runを実行させましょう。

インストール後は、あなたが指示し、Agentが実行する

インストール後の使い方は簡単です：ユーザーが一言指示するだけで、Agentが飛書を操作して仕事を片付けます。

会議が終わった後、AIに「さっきの会議で言及されたすべてのToDoを抽出して、ドキュメントを送るべきものはドキュメントを送り、タスクを作るべきものはタスクを作って」と指示します。AIは議事録を読み、ToDo事項を分解し、それから一つ一つ実行します：lark-cli doc createでドキュメントを作成し、lark-cli task createでタスクを作成し、lark-cli im sendで関係者に通知を送ります。

5人で時差をまたぐ会議を設定したい場合、AIに「来週、みんながいつ空いているか調べて」と指示します。AIは各人のカレンダーとタイムゾーンを確認し、いくつかの時間帯を提案します。ユーザーが一つ選ぶと、会議が作成されます。

AIに飛書ドキュメント内で直接下書きを書いてもらうことさえできます。ユーザーがドキュメント内にコメントを残して意見を述べると、AIはコメントを読み、自ら修正します。コラボレーション全体を飛書から離れることなく行えます。

インストールも簡単です。npm install -g @larksuite/cliを実行し、次に：

npx skills add https://github.com/larksuite/cli -y -g

過去40年間、コンピュータのインターフェースはCLIからGUIへ、文字からアイコンへ、キーボードからタッチスクリーンへと進化し、人間にとってますます使いやすい方向に進んできました。

AI Agent時代、その方向性は逆転しました。ソフトウェアのユーザーはAI Agentになりつつあります。文字の世界のために設計されたインターフェースであるCLIは、まさにAIが最も扱いやすいツールなのです。

Agentがソフトウェアの新しいユーザー成長のポイントになった以上、飛書がCLIを提供するのも当然の流れと言えます。コミュニティがMCPアダプタ層を書くのを待つより、むしろ直接AIネイティブなCLIを作り、完全にオープンソース化し、登録や承認を必要とせず、すべてのAI Agentが接続できるようにするのです。

これにより、避けて通れない問題も生じます：Agentの権限をどう与えるか？ 権限を与えなければ、何もできません。権限が高すぎると、Agentが意図を誤解して取り返しのつかないことをする恐れがあります。結局のところ、Agentにユーザーの代わりに承認をさせたり、全社メールを送信させたりすることはまだできません。dry-runはリスクの一部を軽減できますが、実際にAgentを企業内で大規模に運用するには、権限システム、監査追跡、人と機械の協業の境界線は、まだ模索中です。

しかし、別の角度から考えてみると、かつて私たちが会社の資金を金庫からネットバンキングに移し、契約書を紙から電子サインに移したときも、一歩一歩模索してきました。CLIとdry-runは、おそらくこのプロセスの第一歩です。

そして、飛書がこの取り組みを行うには、他者が簡単には真似できない強みが実はあります：飛書自体が企業コラボレーション分野ですでに十分に成熟しており、メッセージ、ドキュメント、カレンダー、承認、マルチディメンショナルテーブル、タスクといった機能はすべて既に揃っています。今、これらの機能をAIネイティブなCLIを通じてすべて開放することは、おそらく国内でAI Agentに対して最もオープンで、最もフレンドリーな企業向け接続ポイントになるでしょう。このことの価値は単にツールが一つ増えることではなく、むしろAgent時代に向けて真の企業向けインフラストラクチャを構築し、権限、監査、組織能力をエコシステム全体に開放することにあります。業界がAI Agentを実装する上で、非常に重要な一歩となるでしょう。