業務フロー自動化としてのKylon
動く前に、案件の中身を読む自動化。
Kylonは、AIエージェントがチームの一員として業務に参加するワークスペースです。自社の業務文脈を読み、いま使っているツールの中で実際の作業を進めます。
動いている製品画面
チャンネルでの質問に、その場で結果が返る
このページが説明している場面です。業務がすでに置かれているチャンネルで質問すると、エージェントが参照した情報源を挙げ、同じ会話の中に結果が返ります。レポート、更新されたレコード、そして下書きのままのメール。担当者が承認するまで、何も確定しません。
製品自身のスタイルシートで描画したKylonの画面です。企業名、担当者名、数値はすべて架空のものです。
最初にエージェントを置く3つの業務
どれもチャンネルでの質問から始まります。繰り返すべき業務になった時点で、同じ作業をワークフローとして保存します。スケジュール、Webhook、レコードの変更で動き、実行ごとに履歴が残ります。
調査から報告書まで
取引先、市場、競合の名前がチャンネルに出ます。エージェントは情報源と、社内で持っているレコード、そして上のスレッドを読み、チームが議論する場所に報告書を書きます。
誰かが動く前に、担当者が報告書を読みます。
見込み客の反応から、確認済みの連絡まで
フォームが届くか、レコードが変わります。エージェントは相手企業を調べ、その取引先向けのCRMメモを書き、接続したメールボックスから、普段の言い回しで返信を用意します。
メールは下書きのまま待ちます。送るかどうかは担当者が決めます。
定例レポートをチャンネルへ
定期実行のワークフローが同じ4つの情報源をまとめ、前期比で要約を書き、誰も開かないフォルダではなく、数字が議論されているチャンネルに投稿します。
確認できなかった項目は、推計せずにその旨を書きます。
業務プロセスは、長い回答ではありません。分岐し、そして止まります。
同じ週に2社が同じ考え方を発表しました。StonlyのBusiness Process Agentsは、サポートチームがすでに使っている手順書に沿って動き、顧客の発言によって分岐し、判断が必要な場面では人に引き継ぎます。Salesforceは、メモリと持続的な実行、承認の境界を持つエージェントとして説明しています。呼び方は新しくても、業務のかたちは以前からあるものです。会話と業務プロセスを分けるのは次の3点で、いずれもプロンプトの言い回しではなく設定として扱われます。
StonlyのBusiness Process Agents発表、2026年9月18日確認
すでに書かれた手順書のとおりに動く
業務プロセス型のエージェントは、チームが従っている手順書そのものを読みます。モデル向けに書き直した二重の手順書は使いません。Kylonではその手順書がスキルやチャンネルのガイドラインにあたり、一度書けばワークスペース内のどのエージェントも読みます。手順を変えれば、動きも変わります。
きっかけではなく、案件の中身で分岐する
適用可否の確認、規程の解釈、例外処理は、いずれも途中で枝分かれします。エージェントはレコードとスレッドを読んでから分岐を選びます。固定の手順では、分岐のたびに新しい経路を足すことになります。
判断が要るところで止まる
業務プロセスの有用な終点は、完了した操作よりも、準備された操作です。計算まで終えた返金案、根拠とともに提示されたレコードの変更案、書き終えて未送信のままの返信。この停止はワークスペース側の性質なので、どのエージェントが担当しても同じように働きます。
このページの例はKylonの動作を説明したものです。StonlyとSalesforceは用語が広がっている根拠として挙げており、連携先ではありません。
何かに触れる前に
モデルは動けるようになりました。統制は別の判断です。
近年の主要モデルは、説明するのではなく作業そのものを行うと説明されています。フォームへの入力、顧客レコードの更新、調査と文書の作成です。OpenAIはGPT-6 Astraについてそう述べていますが、これはモデルの能力についての説明であり、御社のシステムについての説明ではありません。下の表にあるのは、どのモデルを使う場合でもチームが答えを出す必要がある項目です。Kylonではそれぞれがプロンプトの一文ではなく、ワークスペースの設定になっています。
OpenAIによるGPT-6 Astraの発表、2026年9月16日確認
このページは特定のモデルへの対応を示すものではありません。ここに挙げた設定はワークスペース側の性質であり、そこにいるすべてのエージェントに同じように適用されます。
自動化の前に、エージェントが必要とするもの
- スレッド：先にフォームを埋めるのではなく、その業務が話されているチャンネルを読みます。
- レコード：管理表とテーブルがワークスペースにあるため、書き出しをせずに読み書きします。
- ツール：GmailやSlackからSalesforce、HubSpot、Jira、GitHubまで、3,000を超えるサービスが接続されます。
- メモリ：先月の決定が残っているので、実行のたびに説明し直す手間が減ります。
- 権限：許可した範囲だけを参照し、影響の大きい操作は承認を待ちます。
結果が届く先
- CRM
- Salesforce · HubSpot · Pipedrive · Close · Dynamics 365
- タスク管理
- Linear · Jira · Asana · Trello · ClickUp · monday.com
- ドキュメント
- Notion · Google ドキュメント · Google スプレッドシート · Confluence
- コミュニケーション
- Slack · Gmail · Outlook · Microsoft Teams
使い方
- 01
その業務がすでに置かれているチャンネルで、してほしいことを普通の言葉で伝えます。
- 02
触れるツールを接続し、依存するレコードを指し示します。データを移す必要はありません。
- 03
繰り返すべき業務になったら、スケジュール、Webhook、レコードの変更でワークフローとして保存します。
Kylonがしないこと
これは四角と線をつなぐ画面ではありませんし、どの業務にも向く道具でもありません。同じきっかけで毎回同じ手順を実行するなら、ルール型の自動化のほうが簡単で、動きも読みやすくなります。Kylonが向くのは、手順が案件によって変わり、結果を誰かが見る必要がある部分です。
よくある質問
- Zapier、Make、n8nとの違いは何ですか。
- これらのツールは、あらかじめ定義した順序を実行します。きっかけがあり、毎回同じ処理が動きます。Kylonのエージェントは、その案件の文脈を先に読み、必要なことを判断し、結果を確認用に返します。すでに動いている自動化はそのまま使い、状況を読んでから動く必要がある部分にエージェントを置く形をおすすめします。
- 定期実行もできますか。依頼したときだけですか。
- どちらもできます。チャンネルで依頼することも、スケジュール、Webhook、レコードの変更でワークフローを開始することもできます。実行には履歴が残るので、何がなぜ起きたのかを後から確認できます。
- 先にワークフローを組み立てる必要がありますか。
- ありません。まず業務そのものを依頼します。その一部を繰り返すことになった時点で、ワークフローとして保存します。準備期間も、コードや設定ファイルも必要ありません。
- エージェントが想定外のことをしないようにできますか。
- 権限を範囲で設定します。許可した範囲だけを参照し、影響の大きい操作は実行前に承認を待ちます。管理者、メンバー、エージェントは、それぞれ別の権限階層に置かれます。
- モデル自体がソフトウェアを操作できるようになれば、これは不要になりますか。
- 変わるのはモデルにできることで、ワークスペースが許可する範囲ではありません。フォームに入力できるモデルであっても、動作するためのアカウント、参照範囲の境界、社外に出る操作を見る人、そして何が実行されたかの記録は引き続き必要です。Kylonはこの4つを持っているため、モデルが進歩しても参照範囲を広げずに同じ業務を改善できます。