まず使える：AIに任せる範囲を仕分けするコピペ用プロンプト
先に、この記事の結論を自社に当てはめるためのプロンプトを置いておきます。これはAIにLINEの操作を実行させるためのプロンプトではありません。 AIに自分の環境を読み取り専用で調べさせて、「どの操作から試せるか」「何が足りないか」「どこで人の確認を挟むべきか」を下書きさせるためのものです。
このプロンプトができるのは、判断材料をそろえて仕分けの案を出すところまでです。仕分けの正解を保証するものではありませんし、同じ結果が自動的に再現される保証もありません。最後の線引きは、この記事の後半で説明する基準を読んだうえで、自分で決めてください。
使う前に、Claude CodeなどのMCPクライアントからLINE Harnessに接続できる状態になっている必要があります。接続の手順は「接続の前提と設定：何を用意すればAIから操作できるのか」のセクションで説明します。
あなたはLINE公式アカウントの運用担当者を支援するアシスタントです。
これから私の環境を調査し、「どの操作をAIに任せられるか」の仕分け案を作ってください。
この会話では、実際にメッセージを送る・レコードを作る・レコードを消すといった
書き込み操作は一切実行しないでください。
■ 前提として渡す情報
- 事業・アカウントの用途: [自社のLINE公式アカウントの用途を1〜2行で]
- いま手作業でやっていて重いと感じている業務: [例：毎週の配信文面づくり、タグの整理]
- 運用している公式アカウントの数: [1つ／複数]
- 社内でコマンドライン操作ができる人: [いる／いない／外部に依頼できる]
■ 認証情報の扱い
APIキー・アクセストークン・チャネルシークレット・パスワードは、
この会話に貼り付けません。あなたも私に要求しないでください。
接続情報はMCPクライアントの設定ファイルと環境変数にすでに設定してあります。
■ 手順
フェーズ1（読み取りのみ）
1. あなたがいま呼び出せるLINE Harnessのツール一覧を、名前と説明つきで出力してください。
この記事や一般的な資料の記載ではなく、あなたの環境で実際に使える一覧を根拠にしてください。
2. アカウント概要を取得し、友だち数・タグ・シナリオの規模感を要約してください。
3. タグの一覧を取得し、配信の絞り込み条件に使われていそうなタグと、
社内のメモ用に見えるタグを分けて整理してください。
4. 顧客の個人情報を含むデータ（友だち一覧、友だち詳細、フォーム回答、会話履歴）は、
個票を全件取得しないでください。件数や分類ごとの集計までに留めてください。
フェーズ2（仕分け案の作成）
5. フェーズ1で確認できたツールを、次の3列に仕分けした表を作ってください。
- AIに任せてよい
- AIに準備させ、実行前に人が確認する
- 人だけで行う（AIは診断と手順提示まで）
6. どの列に置くかは感覚で決めず、次の3つの質問を上から順に当てはめ、
最初に「はい」になったところで確定させてください（それ以降の質問は見ません）。
質問1：複数アカウントの運用・BAN対応・アカウント移行に関わる判断か？
→ はい：「人だけで行う」。根拠の列には「1問目が「はい」」と書く
質問2：既存のデータや設定を削除・上書きして、元の状態に戻せなくするか。
または、人や外部サービスに新しくアクセスを渡すか？
→ はい：「AIに準備させ、実行前に人が確認する」。根拠の列には「2問目が「はい」」と書く
質問3：LINEユーザーに届くか、届く内容の素材（メッセージ、画像、
トラッキングリンク、フォーム、リッチメニューなど）を作るか。
または、配信の絞り込み条件に使われるものを変えるか？
→ はい：「AIに準備させ、実行前に人が確認する」。根拠の列には「3問目が「はい」」と書く
3つとも「いいえ」→「AIに任せてよい」。根拠の列には「すべて「いいえ」」と書く。
ただし、顧客の個人情報や個人に紐づく行が返る読み取りは、
そのタスクに必要な件数・項目まで取得範囲を絞る条件を必ず添えてください。
7. 同じツールでも操作の動詞が違えば別の行にしてください。
たとえばタグは、削除・統合と、付け外しと、新規作成を別の行に分けます。
フェーズ3（不足と前提の洗い出し）
8. 仕分けを確定するために私に確認すべきことを、質問形式で列挙してください。
9. あなたが実行できない前提条件（アカウント発行、権限付与、支払い、本人確認など）が
あれば、実行を試みずに「人が先に済ませる必要がある項目」として列挙してください。
■ 守ってほしいこと
- 確認できた事実、推測、私の環境に依存する部分を、必ず区別して書いてください。
- 仕様が変わりうる項目（ツールの構成、APIの仕様、料金、プラットフォームの規約）は、
記憶から答えず、公式ドキュメントの現時点の記載を確認してから書いてください。
確認できない場合は「未確認」と明示してください。
- 数値や実績を、根拠なく補わないでください。
- 書き込み・削除・権限変更・配信は、私が個別に承認するまで実行しないでください。
■ 最初の返答
いきなり全部を実行しないでください。最初の返答は次の4つに限定します。
1. フェーズ1で確認できた現状のチェックリスト
2. 仕分けを進めるために足りていない情報
3. 私が先に済ませる必要がある前提条件
4. これから進める手順の案（フェーズ単位）
プロンプトの手順に埋め込んだ3つの質問は、この記事の最後のセクション「振り分けの判断ルール：3つの質問で決める」で扱うものと同じです。プロンプトはその質問を機械的に当てはめて、仕分けの下書きと、根拠の列までを作ります。ただしなぜその3問なのか、境界にある操作をどちら側に置くのかは、最後のセクションを読んでから自分で確定させてください。 下書きが出た時点では、まだ判断は確定していません。
なおこのプロンプトの構造そのものが、後半で説明する「目的・対象と条件・手順や観点・出力形式」の4点セットと、そこに足すべき制約の例になっています。自社用に書き換えるときの考え方は、プロンプト設計のセクションで扱います。
LINE Harnessの「AI連携」は2つの経路に分かれる
「AI連携」とひとことで言っても、実際には性質の違う2つの経路があります。どちらを使うかで、必要な準備も、任せられる範囲の考え方も変わります。
そもそもLINE Harnessが何であり、有料ツールと何が違うのかを先に押さえたい場合は、LINE Harnessとは何かの全体像をご覧ください。この記事は、その全体像のうちAI連携の部分だけを深掘りするものです。
MCP Server経由：AIツールから自然言語で指示する
ひとつめは、MCP Serverを経由する経路です。MCPは、AIツールと外部システムをつなぐための共通の仕組みで、LINE Harnessはこれに準拠したサーバーを同梱しています。
ドキュメントに記載されている接続の流れは、次のようになっています。
Claude Code / MCPクライアント
↓ (stdio)
MCP Server
↓ (HTTP)
TypeScript SDK
↓ (HTTP + APIキー)
Cloudflare Workers API
↓
データベース + LINE Messaging API
読者から見える動きとしては、Claude Codeに「友だち数を教えて」と書くと、AIがアカウント概要を取得するツールを選んで呼び出し、結果を要約して返す、という形になります。ツール名やAPIのパスを覚える必要はありません。
MCP ServerはSDKのラッパーとして作られています。つまりMCP経由でできることは、原則としてSDKでできることの範囲内です。
API/SDK経由：コマンドやコードでそのまま操作する
ふたつめは、APIを直接呼び出す経路です。保護されたエンドポイントはBearerトークンによる認証が必要で、APIキーはCloudflare側の秘密情報として管理する前提になっています。TypeScriptのプロジェクトであれば、SDKを使って同じ操作をコードから書けます。
SDKにはワークフローヘルパーがあり、複数ステップのシナリオ作成や一斉配信を1行で書ける関数が用意されています。決まった処理を毎回同じ形で流したい場合は、自然言語で指示するより、こちらのほうが結果が安定します。
用意されているエンドポイントの一覧は、OpenAPIの仕様書を返す公開エンドポイントで確認できます。これは認証なしで取得できるため、「いまの環境で何が操作できるのか」をAIに調べさせる入口としても使えます。
管理画面とAIは、同じ機能への別々の入口
ドキュメントは、管理画面を状態の確認用と位置づけ、変更はすべてClaude CodeからAPIを叩く運用を推奨しています。その利点として挙げられているのは、操作の再現性が確保されること、まとめて処理しやすいこと、操作のログが残ることの3点です。
これはあくまでドキュメントが示す推奨であって、実運用でその効果を測定した数値ではありません。また「管理画面を使ってはいけない」という意味でもありません。日々の配信やタグ操作は管理画面からも行える実装になっています。
この設計思想を踏まえると、AI連携の位置づけがはっきりします。AI連携は、管理画面の代わりに用意されたもうひとつの入口です。 AIがなければ立ち行かないわけではなく、AIがあらゆる運用を肩代わりしてくれるわけでもない、という位置づけです。
接続の前提と設定：何を用意すればAIから操作できるのか
ここから先の記述は、冒頭で述べたとおり公式ドキュメントと実装コードを読んで確認した内容です。設定手順についても、私たちが手元で接続を成功させて検証した記録ではありません。 実際の値や画面はバージョンによって変わるため、自分の環境の表示を正として進めてください。
前提として、稼働中のインスタンスとAPIキーが必要
MCP接続の設定を書く前に、操作する相手であるLINE Harness本体が動いている必要があります。ここが最初のつまずきどころです。AI連携は既存の運用基盤に後から足す入口であって、AI連携から始めることはできません。
必要になるのは、デプロイ済みの稼働環境（Cloudflare Workers上のAPI）と、そのAPIを呼び出すためのAPIキーです。LINE公式アカウント側の設定、データベースの初期化、初回のデプロイまでを含む運用基盤の作り方は、AIでLINE運用するには？公式アカウントの運用基盤を作る手順で、似た名前のURLの役割の違いや公開前チェックリストまで含めて解説しています。OSSとしての構成やセルフホストの要件から確認したい場合は、前提となるLINE Harness本体の構築手順で扱っています。
この記事は、その基盤がすでに動いている前提から始めます。
接続設定ファイルにMCPサーバーを登録する
MCPクライアント側では、接続設定ファイル（Claude Codeの場合は .mcp.json）にサーバーを登録します。ドキュメントが推奨しているのは、パッケージをその場で取得して起動する方式です。
{
"mcpServers": {
"line-harness": {
"command": "npx",
"args": ["-y", "@line-harness/mcp-server@latest"],
"env": {
"LINE_HARNESS_API_URL": "https://your-worker.workers.dev",
"LINE_HARNESS_API_KEY": "your-api-key"
}
}
}
}
書く内容は実質2つだけです。自社のAPIのURLと、APIキー。 この2つを環境変数として渡すと、MCPサーバーがその環境に接続します。上の例のURLとキーはプレースホルダなので、自社の値に置き換えてください。
もうひとつ、リポジトリ内のMCPサーバーをローカルでビルドして、そのまま起動する方式もドキュメントに記載されています。パッケージの取得を毎回行いたくない場合や、手元で挙動を確認しながら使いたい場合はこちらです。
そもそもMCPサーバーをAIツールに登録した経験がない場合は、ShopifyをCodex / Claude Codeから触れるようにする設定方法で、別のシステムを題材にMCPサーバーの登録コマンドと、読み取りから段階的に広げていく順番を解説しています。考え方はそのまま応用できます。
APIキーの扱い：画面共有・スクリーンショット・チャットに出さない
APIキーは、Cloudflare側の秘密情報として管理する前提になっています。設定ファイルに直接書き込む例がドキュメントに載っていますが、そのファイルをリポジトリに含めてしまうとキーが共有されます。
実務上、最低限そろえておきたいのは次の3点です。
| 項目 | やること | 理由 |
|---|---|---|
| 保管場所 | 接続設定ファイルをバージョン管理の対象から外すか、環境変数から読む形にする | 設定ファイルごとキーが共有されるのを防ぐ |
| 露出防止 | 画面共有・スクリーンショット・チャットへの貼り付けを避ける | AIとの会話に貼ると、その履歴側にも残る |
| 権限の範囲 | キーが漏れたときに何ができてしまうかを、先に把握しておく | 保護されたエンドポイントは、このキー1つで通る |
AIに認証情報を扱わせないでください。 ログイン、本人確認、支払い、アカウントの復旧といった操作は、AIに代行させるものではなく、人が先に済ませておく前提条件として扱います。
何を任せられるのか：読み取り系・書き込み系・管理系の3系統で見る
MCP経由で呼び出せるツールは、公開ドキュメント上で読み取り系・書き込み系・管理系の3つに分類されています。この分類は、そのまま「AIに任せてよいか」の判断軸にはなりませんが、話を整理する単位としては使えます。
読み取り系：状態を変えずに取得する
読み取り系では、友だち一覧、友だち詳細、フォーム回答、リンククリックの分析、コンバージョンログ、アカウント概要、CRMオブジェクトの一覧を取得できます。加えて、会話履歴を取得するツールも実際に登録されています。
ただし会話履歴のツールについては注意が必要です。これは公開ドキュメントのツール一覧には載っておらず、実装コードの登録からのみ確認できるものです。 現行仕様として断定はできないので、自分の環境のツール一覧に実際に出てくるかを確認してから使ってください。
そして、読み取り系には後半で条件が付きます。友だち一覧、友だち詳細、フォーム回答、会話履歴が返すのは、表示名、LINEユーザーID、タグ、アンケートの回答内容、問い合わせの本文といった実在する顧客の個人情報です。「読み取りは状態を変えないから安全」という説明は、個人情報の観点では成り立ちません。後段の判断シートでは、この4つに取得範囲を絞る条件を付けています。リンククリックの分析やコンバージョンログのように、個人に紐づく行を含むものも同じ扱いです。
書き込み系：ユーザーに届くもの、届く素材になるものを作る
書き込み系では、個別のメッセージ送信、一斉配信、シナリオ作成、シナリオへの登録、フォーム作成、リッチメニュー作成、トラッキングリンク作成、画像アップロードができます。
このグループは、性質が2つに分かれます。個別送信や一斉配信のようにその場でユーザーに届くものと、トラッキングリンクや画像のように単体では届かないが、後から届くメッセージに組み込まれるものです。後者も、最終的にはユーザーの目に触れます。判断シートでは、この両方を同じ列に置いています。
管理系：作る・付ける・外す・消す
管理系では、友だち、タグ、シナリオ、配信、リッチメニュー、フォーム、トラッキングリンク、スタッフ、広告プラットフォームの管理（作成・更新・削除や、付け外し）ができます。
これに加えて、自動応答ルール、メッセージテンプレート、流入経路プールを管理するツールも実装コードには登録されています。 ただしこの3つは、先ほどの会話履歴のツールと同じで、公開ドキュメントのツール一覧には載っていません。自分の環境のツール一覧に出てくるかどうかを確認してから使ってください。
ここも一様ではありません。タグを新しく1つ作ることと、既存のタグ定義を削除して統合することは、失敗したときの戻しやすさがまったく違います。削除や上書きを含む操作は、後段の判断シートで「人が確認」側に固定しています。 スタッフの追加のように、第三者にアカウントの操作権限を渡す操作も同じ扱いです。
ツールの数は資料によって食い違う：自分の環境の一覧で確認する
ここで、ツールの数について触れておきます。公開ドキュメントのツール一覧は、見出しに書かれている数と、その下の表に並んでいる件数が一致していません。 さらに、実装コードには登録されているのにドキュメントの表に載っていないツールがあります。ここまでに挙げた会話履歴、自動応答ルール、メッセージテンプレート、流入経路プールのツールがそれにあたります。
これは私たちのフォークだけで起きている整備遅れではありませんでした。フォーク元の公開されているドキュメントとコードを直接取得して照合したところ、同じ状態が確認できました。
そのため、この記事ではツールの数を断定しません。 代わりに、次の2つを確認導線として案内します。
- 自分のMCPクライアントに表示される、実際のツール一覧を見る
- OpenAPIの仕様書を返す公開エンドポイントで、いま呼び出せるAPIの一覧を確認する
なお、ドキュメントにはMCP Resourcesという別の仕組みのURIも記載されていますが、こちらも記載されている値と実装コード側の値が一致していませんでした。これもフォークだけの話ではありません。フォーク元の公開リポジトリについて、ドキュメントと実装コードの両方を取得して突き合わせたところ、同じずれがそのまま残っていました。どちらが正なのかは実接続で確認できていないため、この記事ではURIを提示しません。
この「ドキュメントと実装がずれている」という事実を、任せる範囲の判断にどう反映するかは、後半の限界のセクションでまとめて扱います。 ここではまず、数を鵜呑みにせず自分の環境を見る、という一点だけ押さえてください。
ドキュメントが示す操作フロー：自然言語の1文がシナリオ3ステップになるまで
ここからは、自然言語の指示がどう実行に変わるのかを見ていきます。
以下は公開ドキュメントに記載された動作の流れであり、私たちが実際に接続して実行した記録ではありません。 記載を確認したのは、私たちが保持しているフォークのコミット時点で、Claude Code連携ガイドが2026年5月23日、MCP Serverのドキュメントが2026年3月28日、ツール登録の実装コードが2026年4月21日です。ツール登録の実装が変わったあと、MCP Serverのドキュメントは更新されていません。自分の環境で挙動を確認してから運用に組み込んでください。
例1：友だち追加時の3ステップシナリオ
ドキュメントに載っている指示は「友だち追加時に挨拶→1時間後にサービス案内→3日後にクーポン送信するシナリオを作って」です。この1文に対して、記載されている処理は次のように分解されています。
| 順番 | 何が作られるか | 指定される値 |
|---|---|---|
| 1 | シナリオ本体 | 名前と、友だち追加をきっかけにする設定 |
| 2 | ステップ1 | 遅延0分のテキストメッセージ |
| 3 | ステップ2 | 遅延60分のテキストメッセージ |
| 4 | ステップ3 | 遅延4320分（3日）のテキストメッセージ |
注目したいのは、「1時間後」「3日後」という日本語が、分単位の数値に変換されているところです。自然言語の指示は、そのまま保存されるのではなく、システムが持っているデータ構造に翻訳されます。だから翻訳がずれれば、意図と違うものが出来上がります。作られたあとに中身を確認する必要があるのは、このためです。
例2：タグ条件を組み合わせたセグメント配信
指示は「VIPタグが付いていて、フォロー中の友だちだけにお知らせを送って」。記載されている処理は、VIPタグのIDを取得し、配信を作成し、2つの条件をANDで結合したセグメント配信を実行する、という順序です。
条件は「そのタグを持っている」と「フォロー中である」の2つで、結合方法が明示されています。ここも同じで、「VIPで、かつフォロー中」という日本語が、条件式に変換されています。 「VIPまたはフォロー中」と解釈されたら、届く相手はまったく変わります。
例3：フォーム作成と回答者への自動タグ付け
指示は「アンケートフォームを作って、回答したら自動でタグ付けして」。記載されている処理は、先にタグを作り、そのタグのIDをフォームの設定に埋め込む、という順序です。フォームには、回答を送信したときに付けるタグと、回答内容を友だちのメタデータに保存するかどうかが指定されます。
3つの例に共通しているのは、1つの指示が複数の呼び出しに分解され、それぞれに具体的な値が埋められていくという構造です。到達点だけを見ると「1文でシナリオができた」ように見えますが、実際には値の決定が何段階も挟まっています。
指示の粒度が粗いとどうなるか
上の例は、対象・条件・タイミングがすべて指示文に含まれています。逆に言えば、それらが欠けている指示では、AIが値を補うことになります。
私たちは、粒度が粗い指示でどう補正されるかを実行して観測したわけではないので、失敗例としては書きません。ただし、製品に同梱されているプロンプトテンプレートが、対象・条件・観点・出力形式を明示する形で書かれているという事実は確認できます。製品側が用意した見本が、その4点を書く前提になっているということです。ここは次のセクションで詳しく扱います。
送信系で必ず知っておくべき副作用：URLの自動トラッキング化と、取り消せない操作
メッセージ中のURLが、トラッキングリンクに自動で置き換わる
個別送信と一斉配信では、メッセージ本文に含まれるURLが、自動的にトラッキングリンクに置き換えられます。クリックを計測するための仕組みです。
実装を追いかけると、テキストメッセージの場合、この置き換えを実際に行っているのはMCPのツール自体ではありませんでした。MCPツールが呼び出すバックエンド（Cloudflare Workers）側で、送信処理の途中に実行されています。 つまりAPIを直接叩いた場合でも同じことが起きます。MCP経由かどうかは関係ありません。
そして、この処理が走るのは個別送信と一斉配信だけではありません。 シナリオのステップ配信も、同じ置き換えを通ってから送信されます。公開ドキュメントは個別送信と一斉配信の2つだけを挙げていますが、実装ではシナリオ配信も対象です。シナリオに仕込んだURLも書いたとおりには届かない、と考えてください。
なお公開ドキュメントには、この処理に関連して「テキストメッセージはボタン付きのFlexメッセージに自動変換される」という記述もあります。しかし実装コードを確認したところ、その変換は現行のコードでは実行されていませんでした。 変換用の関数は存在するものの、どこからも呼び出されていない状態です。フォーク元の公開リポジトリ側でも同じでした。この記事では「メッセージの見た目や形式が変わる」とは書きません。変わるのは本文中のURL文字列だけです。
この置き換えはオフにできる。ただし効く範囲が一様ではない
個別送信と一斉配信は、trackLinksという引数でこの挙動をオフにできます。 公開されているMCPサーバー（npx create-line-harnessでセットアップした場合に実際に使うバックエンドが対象）では、これらのMCPツールにtrackLinks（既定値true）という引数があり、Claudeに「trackLinksをfalseにして送って」と伝えれば、URLをそのまま送信できます。この記事の他の検証はPathosionが自社運用のために保持しているフォークのコードで行っていますが、このフォークはtrackLinksによるオプトアウトの仕組みを持たない古い実装のままです。したがって「送信のたびにfalseを指定できる」という前提は、公式リポジトリの現行リリースを素直にセットアップした場合の話だと考えてください。自社のフォークやカスタム版を使っている場合は、このオプトアウトが効くかどうかを実際に確認してください。
既定値はtrueなので、何も指定しなければ必ず置き換わります。 そして、このオプトアウトはシナリオのステップ配信には効きません。 公式リポジトリの公開リリース（検証時点の最新リリースは v0.17.0。タグとしては v0.18.0・v0.18.1 も存在しますが、これらに対応するGitHub Releaseは本記事の検証時点で公開されていません）のバックエンド実装を3経路とも読んだ範囲では、個別送信は送信リクエストに付いたtrackLinksを、一斉配信は配信レコード側に保存された設定を、それぞれ別の値として参照して自動トラッキングをスキップします。しかしステップ配信の処理には同等の分岐が見当たらず、trackLinksのような指定に関係なく置き換えが走ります。オフにしたい場合はシナリオ配信を使わない、という選択になります。
置き換わると何が変わるか
| 変わるもの | 変わらないもの |
|---|---|
| 本文に書いたURLが、計測用のリンクに置き換わる | メッセージの形式（テキストはテキストのまま） |
| 誰がクリックしたかを後から確認できるようになる | 本文の文章そのもの |
読者に届くメッセージを見ると、書いたURLとは違う文字列のリンクが載っている状態になります。キャンペーンページのURLをそのまま見せたい場合や、リンク先のドメインを読者に確認してほしい場合は、この挙動が意図と食い違います。
対象外になるケースを知っておく
すべてのURLが置き換わるわけではありません。実装コードで確認できた範囲では、次のURLは置き換えの対象から外れます。
- すでにトラッキングリンクになっているURL
- LIFFのURL
- LINEアプリ内で開くディープリンク
- Worker自身のURL
またX、Instagram、YouTube、TikTok、Facebook、GitHubといった、よく使われるプラットフォームのURLは、テキストメッセージで送る場合に限り、トラッキングリンクに置き換えられません。代わりに、外部ブラウザで開くためのパラメータが付きます。リンクのプレビュー表示を優先する設計になっているためです。Flexメッセージで同じURLを送る場合は、これらのドメインでも置き換えが行われます。
ひとつ留保があります。「Worker自身のURL」をどう判定するかは、実装のバージョンによって書き方が違います。既定のドメイン名のパターンに一致するかどうかで判定しているものもあれば、設定値から判定しているものもあります。独自ドメインや短縮用のドメインを使っている環境では、自社のURLが置き換えの対象に入ってしまう可能性があるので、実際に送って確かめてください。
送ったあとに戻せるもの、戻せないもの
「意図しない配信が起きたらどうなるか」を先に整理しておきます。
| 対象 | 実行後に戻せるか |
|---|---|
| 送信済み・配信済みのメッセージ | 戻せない。相手の端末に届いた通知と履歴は消えない |
| 作成したシナリオ・フォーム・トラッキングリンク | 管理系のツールで削除できる |
| 付けたタグ | 外せる |
| シナリオ登録した友だちに、すでに配信されたステップ | 戻せない |
| シナリオ登録した友だちへの、以降のステップ | シナリオ自体を止めれば止まる。ただし特定の友だちだけ登録を外す操作は、確認できた範囲では見当たらない |
最後の行は、実装を確認したうえで書いています。友だちをシナリオに登録するAPIはあります。一方で、APIのルート定義・TypeScript SDK・データベース操作層の3か所を読んだ範囲では、登録した友だちを個別に外すAPIは見当たりませんでした。 登録を進める・止める・完了させる処理はありますが、登録そのものを取り消す処理が見つからない、という状態です。
ないことの証明は、あることの確認より弱くなります。ここは「確認した3か所には無かった」という水準として受け取り、自分の環境のOpenAPI仕様書とツール一覧で、同等の操作が用意されていないかを実際に確かめてください。
そちらでも見当たらない場合は、こう考えることになります。誤った相手を登録してしまうと、以降のステップを止める手段はシナリオ全体の停止しかなく、正しく登録できている他の友だちの配信も一緒に止まります。「あとで個別に外せばいい」という前提で登録を進めないでください。
つまり、戻せないのは「相手に届いてしまった分」で、設定として作ったものは基本的に消せます。 これが判断シートで、作成系と送信系を別の列に置く理由です。
ただし削除は削除で、バックアップがなければ元に戻せません。「消せるから安全」という話ではなく、「届く前なら止められる」という話として受け取ってください。
だからこそ、配信前に人が実物を確認する
ここまでをまとめると、送信系には「送信者が書いた内容と、受信者が受け取る内容がずれる」経路が実装として存在しています。悪い仕組みという意味ではなく、クリック計測のためには必要な処理です。
ただし、この処理はメッセージを送る瞬間に走ります。送ってから「思っていたURLと違う」と気づいても、配信は取り消せません。 テスト送信で実物を確認してから本番の配信を実行する、という手順を人の側に残す理由はここにあります。
プロンプト設計の判断基準：目的・対象と条件・手順や観点・出力形式の4点セット
製品に同梱されたテンプレートから読み取れる共通の型
LINE Harnessの管理画面には、Claude Code用のプロンプトテンプレートが同梱されています。画面ごとに「CCに依頼」というボタンがあり、押すとその画面の業務に対応したテンプレートが表示され、コピーできる仕組みです。友だちのセグメント分析、タグの一括管理、配信メッセージの作成、配信スケジュールの最適化、シナリオ作成、シナリオの効果分析、BANリスク診断、アカウント移行の手順など、画面の役割ごとに用意されています。
これはフォーク独自の追加ではなく、フォーク元の公開リポジトリにも同じ形で存在することを確認しています。自分の環境の管理画面でも同じボタンが見つかるはずです。
テンプレートを読むと、共通した書き方があります。
| 要素 | テンプレートでの書かれ方 |
|---|---|
| 目的 | 冒頭の1行。「◯◯を分析してください」「◯◯を作成してください」 |
| 対象・条件 | 番号付きの項目として、対象、絞り込み条件、種別を指定 |
| 手順や観点の列挙 | 番号付きで、確認する順番や見るべき観点を並べる |
| 出力形式 | 末尾の1行。「レポート形式で出力してください」「作業手順を示してください」 |
ひとつ補足すると、真ん中の2つは1本のテンプレートに両方が並んでいるわけではありません。冒頭の目的と末尾の出力形式は共通で、中央の番号付きリストが、テンプレートによって「条件の指定」だったり「見るべき観点の列挙」だったりします。 作成を依頼するテンプレートは条件寄り、分析を依頼するテンプレートは観点寄りです。自社用に書くときは、この2つを両方書いても構いません。
たとえば配信メッセージ作成のテンプレートは、「一斉配信用のメッセージを作成してください」で始まり、配信目的・ターゲット・メッセージタイプの3項目を並べ、「効果的なメッセージ文面を提案してください」で終わります。冒頭で目的、中身で条件と観点、末尾で出力形式。 この順番が全体を通して守られています。
プレースホルダを人が埋める前提で書かれている
一部のテンプレートには、角括弧で囲まれた空欄が置かれています。同梱テンプレートを全画面ぶん読み出して数えたところ、この空欄は全体で3か所、2本のテンプレートに集まっていました。配信メッセージ作成の「配信目的」が1か所、シナリオ作成の「ターゲット」と「ステップ数」が2か所です。いずれも、その場の状況によって変わる値です。
つまり、大半のテンプレートには空欄がありません。数としては多くありませんが、扱い方の見本にはなります。この形のテンプレートは、そのまま送れば動くものとしてではなく、人が値を埋めてから送るものとして作られています。 AIに渡す前に人が決めることが、フォーマットに組み込まれているわけです。自社用にプロンプトを書くときも、変わる値は空欄にしておいて、送る直前に埋める形にすると、使い回しが効きます。
「分析してほしい」依頼と「実行してほしい」依頼を混ぜない
日々の業務画面に置かれているテンプレートを分類すると、2種類あります。分析や提案を依頼するものと、作業手順を示させるものです。
たとえばタグの一括管理は「未タグの友だちを特定」「行動履歴に基づいたタグ付け提案」「不要タグの整理」と並べたうえで、最後は「作業手順を示してください」で終わります。タグ付けを実行させるのではなく、手順を出させて終わりです。アカウントの健全性を見る画面にある移行手順のテンプレートも、同様に「手順を示してください」で終わります。
ただし例外があります。日常業務の画面とは別に「緊急コントロール」という画面があり、ここに置かれた2本だけは、実行そのものを依頼する形で書かれています。 全配信の即時停止を指示するものと、アカウント移行の実行を指示するものです。前者は「配信予定を下書きに戻す」「シナリオを止める」「自動化ルールを止める」という止める側の操作を並べ、後者は状態の確認から移行の実行までを並べています。
締めの文言も違います。他の画面のテンプレートが「手順を示してください」「レポートしてください」で終わるのに対し、この2本は実行したうえで「停止した件数を報告してください」「各ステップの結果を報告してください」と、事後報告を求める形で終わります。手順を出させて人が実行する設計ではなく、実行させて結果を受け取る設計です。この2本も、フォーク独自の追加ではありません。フォーク元の公開リポジトリの現行リリースを取得して照合したところ、文面まで同一でした。
この2本の存在は、読み方を1つ変えます。「AIに実行させない」は、製品が強制している仕様ではありません。 日常業務の画面では分析と手順提示に寄せ、緊急停止のように人が明示的にそう判断した局面だけ実行依頼型を置く、という置き分けがされている、というのが実際のところです。したがってこの記事の委譲ルールは、製品仕様の説明ではなく、運用側が自分で決める線引きの提案として読んでください。
そのうえで、実務的にも1つのプロンプトで「分析して、そのまま実行して」と書くのは避けたほうが安全です。分析結果の妥当性を人が確認するタイミングが消えるからです。
5点目として、制約と禁止事項を自分で足す
ここから先は、テンプレートから読み取れる型ではありません。送信側のリスクを踏まえた、この記事からの追加提案です。
同梱テンプレートは管理画面の業務単位で作られているため、多くが分析や提案で完結します。しかしAIから配信を扱う文脈では、話が変わります。一斉配信のようにユーザーへ実際に届く不可逆な操作を指示しうる場面では、「何をしてはいけないか」を書いていない指示は危険です。
具体的には、次のような1行を足します。
- 私が個別に承認するまで、送信・配信は実行しないでください
- 指示していない対象へ、送信範囲を広げないでください
- 認証情報を私に要求しないでください、この会話に貼りません
- 確認できていないことは「未確認」と書いてください、推測で補わないでください
4点セットが「何をしてほしいか」を書くものだとすれば、この5点目は「何をしないでほしいか」を書くものです。冒頭のコピペ用プロンプトでも、末尾に同じ役割のブロックを置いています。
自社用に書き換えるときのチェック項目
プロンプトを自社用に作るときは、次の5つがそろっているかを確認してください。これが判断シートの前半にあたる部分です。
| # | 項目 | 確認すること |
|---|---|---|
| 1 | 目的 | 冒頭1行で、何をしてほしいかが言い切れているか |
| 2 | 対象・条件 | 対象、絞り込み条件、種別が具体的に書かれているか。変わる値は空欄にしてあるか |
| 3 | 手順や観点 | 見るべき順番・観点が列挙されているか |
| 4 | 出力形式 | レポートなのか、手順書なのか、表なのかが指定されているか |
| 5 | 制約と禁止事項 | 承認前の実行禁止、範囲の固定、認証情報の非要求、推測の禁止が書かれているか |
【発展】定期実行や外部連携で、人の起動を外す
このセクションは、自力で実装する手順ではありません。 「定常化まで進めると、どこからがエンジニアの領域になるのか」を先に見ておくための見取り図です。ここで挙げる3つは、いずれもコマンドライン操作やサーバー側の設定を伴います。MCPの接続と基本操作を試す段階の次に来る話として、距離感だけ掴んでおいてください。
定期実行：スケジュールからAIを起動する
ドキュメントには、cronやlaunchdから定期的にClaude Codeを起動し、定型レポートを取得させるパターンが記載されています。例として載っているのは、毎週月曜の朝にCVレポートを取得してSlackに投稿する、という1行のcron設定です。
ここまで来ると、人が「レポート出して」と打つ必要すらなくなります。ただし、Slackへの投稿部分は別の連携が前提になります。また、定期実行される処理が読み取りだけなのか、書き込みを含むのかで、リスクの性質がまったく変わります。人の起動を外すということは、人の確認も外れるということです。 定期実行に載せてよいのは、読み取りとレポート生成までにしておくのが無難です。
外部システムの動きを起点にする（受信Webhook）
受信用のWebhookを作成し、外部システムからそこへデータを送ると、イベントが発火して設定済みの自動化ルールが実行される仕組みも記載されています。たとえばECの注文が入ったときに、LINE側で何かを動かす、といった使い方が想定されます。
ここにも、ドキュメントと実装のずれが1つあります。公開ドキュメントは、この受信Webhookを「認証不要の公開エンドポイント」の一覧に載せています。 文字どおりに読むと、URLを知っていれば誰でもデータを送り込めることになります。
しかし実装コードを確認すると、そうではありませんでした。受信Webhookは署名ヘッダーの付いていないリクエストを拒否し、Webhookごとに設定された秘密鍵で署名を検証してから処理に進みます。ドキュメントが言う「認証不要」は、他のAPIで使うAPIキーによる認証を使わないという意味であって、誰でも送れるという意味ではありませんでした。
秘密鍵の長さは、2段階で担保されています。まずWebhookを作成・更新する時点で、最小文字数に満たない秘密鍵は登録自体が拒否されます。そのうえで受信時にも、秘密鍵が未設定だったり短すぎたりする場合は、署名を検証する前に処理を止める作りになっています。設定が不十分なら通してしまうのではなく、止まる側に倒してあるということです。なおこの受信Webhookの実装は、フォークとフォーク元の公開リポジトリの現行リリースで一字一句同じであることを確認しています。フォーク固有の挙動ではありません。
とはいえ、外部から呼ばれる入口を作ることに変わりはありません。URLと秘密鍵の管理、そして受け取ったデータをそのまま自動処理に流してよいのかという設計は、人が決める領域として残ります。
決済イベントからタグとスコアを動かす（Stripe連携）
Stripeを使っている場合、決済データのメタデータに友だちのIDを設定しておくと、決済成功時のスコア加算、商品IDに応じたタグ付与、サブスクリプション解約時のタグ付与が動く、と記載されています。Stripeを使っていない場合は該当しません。
この3つに共通するのは、一度組んだら人の手を離れて動き続けるという点です。だからこそ、組む前の設計と、組んだあとの監視が必要になります。
AI連携の限界と、人が判断すべきこと
AIに任せない5つの判断と、その理由
ここまでの内容を踏まえると、AIに渡してはいけない判断がいくつか浮かび上がります。
| 判断 | なぜ人が持つのか |
|---|---|
| 配信内容の最終確認 | 配信は取り消せない。URLの自動置き換えもあるため、実物を見ないと確定できない |
| 送信対象の妥当性 | 条件式の翻訳がずれると、届く相手が変わる。人数と条件は人が確認する |
| 認証情報と公開URLの扱い | APIキーは保護されたエンドポイントを1つで通す。会話に貼らない、AIに要求させない |
| 顧客の個人情報をどこまでAIに渡すか | 読み取りは元に戻せるが、渡した個人情報は取り消せない |
| 既存レコードの削除・上書き | バックアップがなければ復旧できない |
4つめについて補足します。友だち一覧や会話履歴をAIに読ませた時点で、そのデータはAIクライアント側のコンテキストと、その提供事業者側の処理に渡ります。「読み取りだから元に戻せる」ことと、「外に出さなくてよい」ことは別の問題です。 実務上は、タスクに必要な件数と項目まで取得範囲を絞るのが現実的です。全顧客データを一括でAIとの会話に流し込む使い方は避けてください。なお、自社の個人情報の取扱方針や委託先の条件でAIクライアントの利用が許容されるかどうかは、読者側でご確認ください。
複数アカウント運用・BANリスク・アカウント移行は人の判断領域
複数のLINE公式アカウントを運用している場合、アカウントの状態監視、危険と判定されたときの対応、別アカウントへの移行といった操作が出てきます。この領域は、判断を誤ったときの回復コストが大きく、実行の順序が結果を左右します。
製品に同梱されているテンプレートが「通常の画面では手順提示、緊急コントロールの画面だけ実行依頼」という置き分けをしていることは、プロンプト設計のセクションで見たとおりです。実行させないことが強制されているわけではありません。
この記事では、通常時の扱いに合わせます。AIは診断と手順の提示まで、実行は人が行う領域です。緊急時に実行を依頼するかどうかは、そのとき人が判断することであって、あらかじめAIに渡しておく権限ではありません。
複数アカウント運用とBAN対策を含む日常運用の手順そのものは、複数アカウント運用とBAN対策の実務手順で扱います。
ドキュメントと実装がずれている領域は、実機で確認してから任せる
この記事の中で、公開ドキュメントの記載と実装コードが一致しない箇所を4つ挙げました。
| 箇所 | 状態 |
|---|---|
| ツール一覧 | 実装に登録されているのにドキュメントの表に載っていないツールがある。フォーク元の公開リポジトリでも同じ |
| MCP ResourcesのURI | ドキュメントの記載と実装コードの値が一致しない。どちらが正かは未確認。フォーク元の公開リポジトリでも、ドキュメント・実装コードの両方が同じ状態 |
| テキストメッセージのFlex変換 | ドキュメントには記載があるが、実装コードでは実行されていない |
| 受信Webhookの「認証不要」表記 | ドキュメントは公開エンドポイントとして分類しているが、実装は署名の検証を必須にしている。フォーク元の公開リポジトリでも同じ実装 |
注意しておきたいのは、ずれの向きが一定ではないことです。ドキュメントにあって実装にないもの（Flex変換）、実装にあってドキュメントにないもの（一部のツール）、そしてドキュメントを読むと実装より危険に見えるもの（受信Webhook）が、いずれも混ざっています。 どちらか片方だけを見て安全側・危険側に寄せる、という読み方はできません。
これは製品を批判するための指摘ではありません。AIに操作を任せる判断を、ドキュメントの記載だけを根拠に行うと危ないという実例です。 ドキュメントは仕様の意図を知るために読み、実際に動く範囲は自分の環境で確認する。この二段構えが必要になります。
具体的には、自分のMCPクライアントに表示されるツール一覧と、OpenAPIの仕様書を返すエンドポイントの2つを、任せる範囲を決める前に見てください。
自力で試せる範囲と、相談したほうが早い範囲
最後に、境界を明示しておきます。
| 範囲 | 内容 |
|---|---|
| 自力で試せる | MCPサーバーの接続設定、読み取り系ツールでの現状確認、テスト対象での書き込みの試行 |
| 相談したほうが早い | 複数アカウント運用やBAN対策を踏まえた自動化の運用設計、定期実行・受信Webhook・外部決済連携といった定常化の設計と運用 |
接続して読み取りを試すところまでは、この記事の内容で進められます。一方、下段の設計は、自社のアカウント構成、既存の運用フロー、社内で誰がコマンドライン操作を担えるかによって答えが変わります。そこまで進めたい場合は、記事末尾のLINEからご相談ください。自社の条件をうかがったうえで、どこから自動化できるかの整理からお手伝いします。
自社で試すときの順番（AIに任せる範囲の判断シート）
ここからは、自社に当てはめるための実務パートです。
ステップ順のチェックリスト
いきなり書き込みから試さないでください。この順番で進めると、途中で問題が起きても戻せます。
| # | ステップ | 完了の目安 |
|---|---|---|
| 1 | 稼働環境とAPIキーを確認する | APIが応答し、キーが手元にある |
| 2 | 接続設定ファイルにMCPサーバーを登録する | AIツールを再起動し、LINE Harnessのツールが一覧に出る |
| 3 | 実際のツール一覧を出力させる | この記事の説明と自分の環境の差分を把握できた |
| 4 | 読み取り系だけで現状を確認する | アカウント概要とタグ一覧を、個票を全件取らずに要約できた |
| 5 | 書き込み系をテスト対象で試す | 自分だけが友だちのテストアカウントに、テスト送信できた |
| 6 | 実物を見て、置き換えの挙動を確認する | 本文に入れたURLがどう表示されるかを目視で確認できた |
| 7 | 判断シートを自社用に埋める | どの操作をどの列に置くかを決め、社内で共有できた |
| 8 | 定常化を検討する | 読み取りとレポートに限定した定期実行から始める |
ステップ6まで終わってから、ステップ7の仕分けを確定させてください。実際の挙動を見る前に線を引くと、机上の分類になります。
ステップ7で使う道具は、このすぐ下の2つのセクションにあります。次のセクションが仕分けの判断ルール、その次が判断ルールを適用した一覧表です。
振り分けの判断ルール：3つの質問で決める
どの操作をどの列に置くかは、次の3問を上から順に当てはめて決めます。最初に「はい」になったところで確定し、それ以降は見ません。
- その操作は、複数アカウントの運用・BAN対応・アカウント移行に関わる判断か？（この領域は、判断を誤ったときの回復コストが大きく、実行の順序が結果を左右します） → はい：人だけで行う（AIは診断・手順提示まで）
- （1が「いいえ」の場合）その操作は、既存のデータや設定を削除・上書きして、元の状態に戻せなくするか。または、人や外部サービスに新しくアクセスを渡すか？ → はい：AIに準備させ、実行前に人が確認する
- （1・2が「いいえ」の場合）その操作は、LINEユーザーに届くか、届く内容の素材（メッセージ、画像、トラッキングリンク、フォーム、リッチメニューなど）を作るか。または、配信の絞り込み条件に使われるものを変えるか？ → はい：AIに準備させ、実行前に人が確認する → すべて「いいえ」：AIに任せてよい。ただし、顧客の個人情報や個人に紐づく行が返る読み取りは、そのタスクに必要な件数・項目まで取得範囲を絞る
この3問は、順番に意味があります。1問目で判断の重さ、2問目で取り返しのつかなさ、3問目で外部への到達を見ています。重いものから先に落とす順序なので、上で止まったら、そこから下は見ません。 そして全体を通して、「便利かどうか」ではなく「戻せるかどうか」で切っている点だけ押さえておいてください。
「任せる／人が確認／人だけ」に振り分けた一覧表
上の3問を適用した結果が次の表です。根拠の列は、3問のどれで決まったかを示しています。自社の操作がこの表にない場合は、根拠の列を手がかりに、同じ3問を当てはめてください。
| 操作 | 系統 | 振り分け | 根拠 |
|---|---|---|---|
| BANリスクへの対応・アカウント移行 | 判断行為 | 人だけで行う | 1問目が「はい」：回復コストが大きく、順序が結果を左右する |
| 流入経路プールの切り替え（友だち追加の受け先アカウントの変更） | 管理 | 人だけで行う | 1問目が「はい」：友だち追加をどのアカウントで受けるかを変える、複数アカウント運用そのものの判断 |
| タグ定義の削除・統合 | 管理 | AIに準備させ、人が確認 | 2問目が「はい」：既存のタグ定義が消える |
| シナリオ・フォーム・トラッキングリンクの削除 | 管理 | AIに準備させ、人が確認 | 2問目が「はい」：既存のレコードが消える |
| 友だちのメタデータの上書き | 管理 | AIに準備させ、人が確認 | 2問目が「はい」：既存の値が上書きされる |
| 配信設定・リッチメニューの上書き | 管理 | AIに準備させ、人が確認 | 2問目が「はい」：既存の設定が上書きされる |
| 自動応答ルール・メッセージテンプレートの編集 | 管理 | AIに準備させ、人が確認 | 2問目が「はい」：既存の内容が上書きされる |
| スタッフの追加・権限付与・削除 | 管理 | AIに準備させ、人が確認 | 2問目が「はい」：第三者にアカウント操作権限を渡す |
| 広告プラットフォーム連携の接続・認証設定 | 管理 | AIに準備させ、人が確認 | 2問目が「はい」：外部サービスへの接続が常設で残る |
| 個別メッセージの送信 | 書き込み | AIに準備させ、人が確認 | 3問目が「はい」：ユーザーに届く |
| 一斉配信・セグメント配信 | 書き込み | AIに準備させ、人が確認 | 3問目が「はい」：ユーザーに届く |
| シナリオと配信ステップの作成 | 書き込み | AIに準備させ、人が確認 | 3問目が「はい」：届く内容そのものを作る |
| 友だちのシナリオ登録 | 書き込み | AIに準備させ、人が確認 | 3問目が「はい」：登録した時点で配信が始まる |
| フォームの作成 | 書き込み | AIに準備させ、人が確認 | 3問目が「はい」：ユーザーが見る内容を作る |
| リッチメニューの新規作成 | 書き込み | AIに準備させ、人が確認 | 3問目が「はい」：ユーザーの画面に出るものを作る |
| トラッキングリンクの作成 | 書き込み | AIに準備させ、人が確認 | 3問目が「はい」：配信に組み込まれる素材を作る |
| 画像のアップロード | 書き込み | AIに準備させ、人が確認 | 3問目が「はい」：配信に組み込まれる素材を作る |
| 自動応答ルールの新規作成 | 管理 | AIに準備させ、人が確認 | 3問目が「はい」：条件に合致した相手に自動で届く |
| メッセージテンプレートの新規作成 | 管理 | AIに準備させ、人が確認 | 3問目が「はい」：配信に組み込まれる素材を作る |
| 配信の絞り込みに使うタグの付け外し | 管理 | AIに準備させ、人が確認 | 3問目が「はい」：配信の絞り込み条件が変わり、届く相手が変わる |
| 配信条件に使わない社内メモ用タグの新規作成 | 管理 | AIに任せる | すべて「いいえ」：削除・上書き・権限付与を含まず、配信条件も変えない新規作成 |
| アカウント概要の取得 | 読み取り | AIに任せる | すべて「いいえ」：参照のみで状態が変わらない |
| タグ一覧の取得 | 読み取り | AIに任せる | すべて「いいえ」：参照のみで状態が変わらない |
| CRMオブジェクト一覧の取得 | 読み取り | AIに任せる | すべて「いいえ」：参照のみで状態が変わらない |
| 友だち数・タグ数などの件数集計 | 読み取り | AIに任せる | すべて「いいえ」：参照のみで状態が変わらない |
| 友だち一覧・友だち詳細の取得 | 読み取り | AIに任せる（取得範囲を限定） | すべて「いいえ」：参照のみ。個人情報を返すため、必要な件数・項目に絞る |
| フォーム回答の取得 | 読み取り | AIに任せる（取得範囲を限定） | すべて「いいえ」：参照のみ。個人情報を返すため、必要な件数・項目に絞る |
| 会話履歴の取得 | 読み取り | AIに任せる（取得範囲を限定） | すべて「いいえ」：参照のみ。問い合わせ本文を返すため、必要な件数・項目に絞る |
| リンククリック・コンバージョンログの取得 | 読み取り | AIに任せる（取得範囲を限定） | すべて「いいえ」：参照のみ。個人に紐づく行を含むため、集計単位に絞る |
表は、3問で先に止まったものから順に並べてあります。同じツールでも操作の動詞が違えば別の行になります。たとえばタグは、削除・統合が2問目、配信条件に使うタグの付け外しが3問目、配信条件に使わないタグの新規作成がすべて「いいえ」で、3つの列に分かれます。
配信は取り消せません。 「AIに準備させ、人が確認」の列にある操作は、AIに下書きまで作らせて構いませんが、実行の引き金は人が引いてください。
「AIに任せる」の列に入っているのは、参照するだけで状態が変わらない操作と、削除・上書き・権限付与を含まず、配信の絞り込み条件も変えない新規作成だけです。この3つの条件のうち1つでも外れたら、その操作は「人が確認」側に移ります。
まとめ
LINE HarnessのAI連携は、MCP Server経由とAPI/SDK直接の2経路。接続に必要なのは、稼働中のインスタンスと、APIのURLとAPIキーの2つだけです。そこから先は、自然言語の指示で友だち・タグ・配信・シナリオ・フォームを操作できます。
ただし、任せる範囲は「便利かどうか」ではなく「戻せるかどうか」で切ってください。送信系にはURLの自動置き換えという副作用があり、配信は取り消せず、公開ドキュメントは実装のすべてを反映していません。 この3つが、線を引く理由です。
進め方としては、接続して読み取りだけで現状を確認するところから始め、実際のツール一覧と実際の送信結果を自分の目で見てから、判断シートを自社用に埋めるのが安全です。定期実行や外部連携まで進める段階は、その先の設計の話になります。