# 2026年のコンテキストエンジニアリング：その意味、プロンプトエンジニアリングとの違い、Claude Codeでの活用方法

> コンテキストエンジニアリングとは何か、プロンプトエンジニアリングとどう異なるのか。Anthropicの基本資料、7つの失敗、Claude Codeの最小構成。

Source: https://ailoot.ai/blog/ja/context-engineering/
Canonical: https://ailoot.ai/blog/ja/context-engineering/
Language: ja
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-037
Revision: sha256-c5f1274104188e57612397f6f75999f5a14d0822f436762f62987ab46fb65759


<div class="aside" data-semantic="key-takeaway" role="note" aria-label="このセクションの重要なポイント">

重要なポイント

コンテキストエンジニアリングとは、メッセージを送る前にClaudeのコンテキストウィンドウへ入るすべての要素、すなわちシステムプロンプト、ツール、履歴、メモリファイル、ツールからのデータを設定する技術です。2026年には、重要なスキルとしてプロンプトエンジニアリングに取って代わりました。Anthropicがそう述べています。このガイドでは、一次資料に基づく基本資料、トークンを浪費する7つのよくある間違い、Claude Code向けの実践的な7ステップのセットアップを紹介します。

</div>

Ailootの利用方法については、[ドキュメント](https://ailoot.ai/docs/)をご覧ください。



## コンテキストエンジニアリングとは？一言で言うと

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="このセクションの重要なポイント">

重要なポイント

コンテキストエンジニアリングとは、各ステップでAIエージェントのコンテキストウィンドウに入るすべての情報、すなわちシステムプロンプト、ツール、履歴、メモリファイル、外部ソースからのデータを選び整える技術です。プロンプトエンジニアリングが答えるのは「プロンプトをどう書くか？」という問いです。コンテキストエンジニアリングが答えるのは「プロンプトを書くとき、AIは何を知っているか？」という問いです。

</div>

Anthropicは2025年9月29日のエンジニアリングブログ記事で、この用語を定義しました。

<figure>
<blockquote>
コンテキストエンジニアリングとは、プロンプト自体以外に入力されるすべての情報を含め、LLMの推論中に最適なトークン（情報）の集合を選び、維持するための一連の戦略です。
</blockquote>
<figcaption>— Anthropic Applied AI team, https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents</figcaption>
</figure>

同じ記事には、視点を変えるうえで最も重要な一節があります。

<figure>
<blockquote>
言語モデルとの作業は、プロンプトの適切な言葉や表現を探すことから、より広い問い、つまり「望ましいモデルの振る舞いを最も生み出しやすいコンテキスト構成は何か？」に答えることへと移りつつある。
</blockquote>
<figcaption>— Anthropic Applied AI team, https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents</figcaption>
</figure>

要点は、コンテキストは自分が書くメッセージではないということです。コンテキストとは、メッセージの**前に**AIが目にする情報全体、すなわちシステムプロンプト、ツールの説明、会話履歴、メモリファイル、MCP経由で読み込まれたデータです。プロンプトは最後のステップです。コンテキストエンジニアリングとは、ウィンドウに入れるすべての情報の設計です。

## なぜ2026年にプロンプトエンジニアリングは時代遅れになったのか？

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="このセクションの重要なポイント">

重要なポイント

プロンプトエンジニアリングは、モデルが単一のプロンプト、つまり1ターンで1つのタスクを処理していた時代に生まれました。2026年のAIエージェントは、ツール、メモリ、サブエージェント、ツール経由でその場で取得するデータを使い、長時間のセッションを実行します。この構成では、単一のプロンプトの言い回しを工夫することが主要なスキルではなく、エージェントが目にする情報全体を整えることが重要です。

</div>

この変化は2025年の夏に起こりました。

**2025年9月29日：** Anthropicがエンジニアリングブログ記事でこの分野を確立し、4つの原則をまとめました。

プロンプトエンジニアリングが「死んだ」わけではありません。キーボードで文字を打つ方法を知っているのと同じように、基礎的なリテラシーになったのです。その上に、長いタスクでAIエージェントが破綻しないための分野、すなわちコンテキストエンジニアリングが生まれました。

## コンテキストエンジニアリングとプロンプトエンジニアリングの違いは？5つの違い

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="このセクションの重要なポイント">

重要なポイント

プロンプトエンジニアリングは単一のプロンプトを最適化します。言い回し、テンプレート、トーンを選ぶ作業です。コンテキストエンジニアリングは、そのプロンプトを送る前の情報環境全体を設計します。システムプロンプト、ツール、セッション履歴、メモリファイル、検索による情報取得が対象です。この違いは、最適化対象、時間軸、主なリスク、中核となるスキル、プロジェクト内の情報源という5つの側面に現れます。

</div>

| 項目 | プロンプトエンジニアリング | コンテキストエンジニアリング |
|----|----|----|
| **最適化対象** | 単一プロンプトの言い回し | トークン全体：システムプロンプト + ツール + 履歴 + 取得データ |
| **時間軸** | 1ターン | 複数ターンとセッション間の移行 |
| **主なリスク** | モデルがプロンプトを理解しない | モデルがノイズに埋もれる（コンテキスト劣化） |
| **中核となるスキル** | コピーライティングとモデルの理解 | 情報設計と対象を絞った検索 |
| **プロジェクト内の情報源** | プロンプトテンプレート | CLAUDE.md、メモリファイル、検索、サブエージェント、コンパクション |
| **たとえ** | 「プロンプトの書き方」 | 「プロンプトを送るとき、AIが何を知っているか」 |

コンテキストエンジニアリングは「とにかく多く入れる」ことではありません。**適量を精密に与えること**です。少なすぎれば、AIはコンテキスト不足になり、幻覚を起こします。多すぎれば、ノイズに埋もれ、途中で要点を見失い、コストも増えます。

プロンプトエンジニアリングが扱っていたのは最後のステップです。コンテキストエンジニアリングは、その前にあるすべてを扱います。



## 100万トークンあっても、なぜ「全部入れる」べきではないのか？

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="このセクションの重要なポイント">

重要なポイント

2026年にはモデルのコンテキストウィンドウが拡大し、Claude Opus 4.7とSonnet 4.6は100万トークンに対応しています。これにより、リポジトリ全体をウィンドウに入れられるという錯覚が生まれます。実際には、ウィンドウが大きくても有用なメモリが増えるとは限らず、モデルの性能は上限に達するかなり前から低下し始めます。

</div>

Claudeモデルの現在のコンテキスト上限は次のとおりです。

| モデル | コンテキストウィンドウ | 利用可能なプラン |
|-------------------|--------------------|--------------------------|
| Claude Haiku 4.5 | 200,000トークン | すべてのプラン |
| Claude Sonnet 4.6 | 1,000,000トークン | 使用クレジット付きPro+ |
| Claude Opus 4.7 | 1,000,000トークン | Pro、Max、Team、Enterprise |

100万トークンは、テキスト約2,500ページ分です。プロジェクトのドキュメント、やりとり、仕様書をすべて読み込ませて、AIに判断させればよいように思えます。しかしAnthropicはエンジニアリングブログで明言しています。

<figure>
<blockquote>
コンテキストは、限界効用が逓減する有限のリソースとして扱うべきです。
</blockquote>
<figcaption>— Anthropic Applied AI team, https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents</figcaption>
</figure>

つまり、コンテキストは限界効用が逓減する有限のリソースです。トークンを追加しても、効果が比例して増えるわけではありません。ウィンドウが長くなるほど、モデルはその中の情報をうまく扱えなくなります。

2026年の主要なスキルは、すべてを開いたままにしておくことではありません。タスクごとに狭いコンテキストを用意し、素早く切り替えることです。

## 最大の間違い：コンテキストが多いほど、結果は悪くなるのか？

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="このセクションの重要なポイント">

重要なポイント

コンテキストが長いほど、モデルはその中の情報をうまく扱えなくなります。この現象はコンテキスト劣化と呼ばれます。「Lost in the Middle」効果も影響します。モデルはコンテキストの冒頭と末尾を覚える一方で、途中を読み飛ばします。実践的な結論は、長いメモリファイルは逆効果だということです。

</div>

もう1つの効果、「Lost in the Middle」も並行して働きます。

実際には、重要なルールがCLAUDE.mdの途中にあると、モデルが読み飛ばす可能性があります。

AnthropicはCLAUDE.mdのドキュメントで、長さの上限を推奨しています。

<figure>
<blockquote>
CLAUDE.mdは200行未満を目安にしてください。ファイルが長いほどコンテキストを消費し、指示への準拠が低下します。
</blockquote>
<figcaption>— Anthropic, https://code.claude.com/docs/en/memory</figcaption>
</figure>

引用の200行未満は長さの目標で、ルール追従が止まる厳密な境界ではありません。80〜120行は紹介したプロジェクトでの筆者の好みで、別のAnthropic要件ではありません。関連する指示を保ち、重要ルールに従うか実際に試してください。行が増えるほど注意と文脈を使います。この上限に収まるようCLAUDE.mdを設定する方法については、[「2026年版CLAUDE.mdの設定方法」](https://ailoot.ai/blog/ja/claude-md-template/)をご覧ください。

## Anthropicが示すコンテキストエンジニアリングの5原則

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="このセクションの重要なポイント">

重要なポイント

Anthropicは2025年9月29日のエンジニアリングブログで、コンテキストに関する基本戦略を5つ挙げました。有限のリソース、必要なときに取得する情報、構造化されたメモ、コンパクション、サブエージェント構成です。これが、現在このテーマを扱う他の著者が引用する基本資料です。

</div>

### 原則1. コンテキストは有限のリソース

これは基本的な前提であり、これがなければほかの4原則は機能しません。Anthropicは次のように述べています。

<figure>
<blockquote>
システムプロンプト、ツール、例、メッセージ履歴など、コンテキストを構成するすべての要素について、よく考慮し、情報量がありながら密度の高いコンテキストを保つことが一般的な推奨事項です。
</blockquote>
<figcaption>— Anthropic Applied AI team, https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents</figcaption>
</figure>

「密度が高い」とは、「余分なものがなく、情報が詰まっている」という意味です。ウィンドウ内のトークンはすべて、モデルの判断に実質的な影響を与えるべきです。CLAUDE.mdに「きれいなコードを書くように努める」とあれば、削除できます。情報としての価値がないからです。

### 原則2. 必要なときに情報を取得する

AIエージェントは、すべてをあらかじめウィンドウに読み込むのではなく、ツールを使ってその場でデータを取得します。これはClaude Codeの構成です。ベクトルデータベースやインデックスの代わりに、エージェントは現場のエンジニアが手作業でコードを検索するように、`glob`と`grep`を使います。

使う場面：タスクでどの箇所が必要になるか、**事前に分からない**場合。

### 原則3. 構造化されたメモを取る

エージェントはメモを外部ストレージに書き、必要に応じて読み込みます。Claude Codeでは、これをメモリツールで実現します。AnthropicはCookbookで次のように説明しています。

<figure>
<blockquote>
メモリとは構造化されたメモです。エージェントは永続的な外部ストレージに書き込み、すべてをアクティブなコンテキストに置き続けることなく、タスクやセッションをまたいで進捗を追跡します。
</blockquote>
<figcaption>— Anthropic Cookbook, https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools</figcaption>
</figure>

使う場面：長いセッション、セッション間の移行、蓄積されるプロジェクト知識。

### 原則4. コンパクション

上限が近づいたときに、メッセージ履歴を要約に圧縮します。Claude Codeでは、`/compact`コマンドのほか、ウィンドウが約80%に達したときの自動コンパクションがあります。Anthropicは次のように述べています。

<figure>
<blockquote>
コンパクションは、ウィンドウが大きくなりすぎたときに、ウィンドウ全体を圧縮します。
</blockquote>
<figcaption>— Anthropic Cookbook, https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools</figcaption>
</figure>

使う場面：分析的な会話が長くなり、チャット履歴が役に立たない情報となって、支援するどころかウィンドウを埋めている場合。

### 原則5. サブエージェント構成

専門化したサブエージェントがそれぞれのコンテキストウィンドウで並行して作業し、圧縮した要約をリードエージェントに返します。Anthropicは次のように述べています。

<figure>
<blockquote>
サブエージェントは圧縮に役立ちます。それぞれのコンテキストウィンドウで並行して作業し、1つの質問の異なる側面を同時に調査します。
</blockquote>
<figcaption>— Anthropic Engineering, https://www.anthropic.com/engineering/multi-agent-research-system</figcaption>
</figure>

Anthropic社内テストの数値によると、リードのClaude Opus 4とサブエージェントのClaude Sonnet 4を組み合わせると、調査タスクの品質はClaude Opus 4単独より<strong>+90.2%</strong>向上します。代償はトークンが約15倍になることです。結論として、成果に価値がある場面では正当化されます。

Claude Codeでサブエージェントを設定する方法については、[「Claude Codeのサブエージェント」](https://ailoot.ai/blog/ja/claude-code-subagents/)をご覧ください。

## トークンを浪費し、Claude Codeを壊す7つの間違い

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="このセクションの重要なポイント">

重要なポイント

プロジェクトの実例を使って、よくあるアンチパターンを7つ紹介します。どれもメリットなくトークンを浪費するか、コンテキスト劣化による幻覚を引き起こします。それぞれの下に、コンテキストエンジニアリングでの対処法を示します。

</div>

| \# | アンチパターン | 起きること | 対処法 |
|----|----|----|----|
| 1 | **README全体とコードファイル5つを1つのプロンプトに貼り付ける** | 1ターンでウィンドウの50%を使い、その後すぐに上限に達する | 長期的な事実にはメモリツールを使い、必要に応じて情報を取得する。`read_file`/`glob`を使ってClaude自身にファイルを読ませる |
| 2 | **500行のCLAUDE.md** | 長い指示は、重要ルールが中間に埋もれる場合などに、遵守を弱めることがある | 80～120行にし、命令形を使い、コマンドとスタイルのセクションを設ける。最重要事項は冒頭と末尾に置く |
| 3 | **長いセッションで`/compact`を実行しない** | セッションが180kトークンに達し、Claudeが最初のメッセージを忘れ、手作業でコンテキストを繰り返すことになる | `/compact`を手動で実行するか、トリガーによる自動コンパクションを使う。負荷の兆候はClaudeデスクトップのコンテキスト使用量インジケーター |
| 4 | **何でも1つのClaudeに任せる** | 1つのエージェントが計画、検索、コーディング、レビュー、テストを行い、ウィンドウが指数関数的に膨らむ | サブエージェントを使う。それぞれが独自のコンテキストを持ち、リードエージェントが要約を集める。Anthropicの調査では、調査タスクの品質が+90.2%向上 |
| 5 | **ツールの結果でメモリファイルが膨らむ** | エージェントが同じファイルを5回読み直し、ツール呼び出しの結果がコンテキストの96%を占める | ツール結果を整理する。直近の4～6件だけを保持し、残りを消去する。呼び出しがあった事実は保持される |
| 6 | **リポジトリ全体を`examples/`フォルダーに貼り付ける** | AIは200個の例からパターンを探し、迷子になる | `examples/`にはタスクの種類ごとに3～7個の代表的なパターンを置く |
| 7 | **200行のMarkdownリストを「機能計画」にする** | 長く構造化されていない一覧は追跡を難しくする。50行目という普遍的な失敗点はない | HTML成果物か、別ファイルの番号付き計画にする |

AnthropicのCookbookは、5番目の間違いに関する具体的な測定結果を示しています。ベースラインのセッションでは、最初の文書（線虫C. elegansに関するもの）は技術的にはコンテキスト内にありましたが、33万5千トークンの下に埋もれていました。存在はしていても、実際にはモデルが思い出せなかったのです。メモリツールを使うと、元のコーパスを再読み込みする代わりに、`aging_model_organisms_comparison.md`というメモファイルを約3,000トークンで扱えます。

身近な例で言えば、コンテキストウィンドウは机です。200個の書類が置かれていれば、必要な書類がそこにあっても見つけられません。コンテキストエンジニアリングとは、「今、机の上に必要なものだけを置き、残りを保管し、必要に応じて読み込む」技術です。

## ひと晩で実用的なセットアップを組むには？

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="このセクションの重要なポイント">

重要なポイント

Claude Codeで最低限の実用的なコンテキストエンジニアリングを構成する要素は7つです。CLAUDE.md、examples、PRPドキュメント、メモリツール、/compact、サブエージェント、ツールを使った必要に応じた情報取得です。基本の枠組みは30～40分で設定できます。例と検証済みプロンプトを含む完全な設定には、ひと晩かかります。使いながら改善できます。

</div>

順番に行う7つのステップは次のとおりです。

1. **80～120行のCLAUDE.md。** プロジェクトのルートに置きます。説明文ではなく命令形を使います。Anthropicは[公式ドキュメント](https://code.claude.com/docs/en/memory)で、`Specificity`の原則、つまりルールは一般論ではなく具体的で曖昧さのないものにすることを推奨しています。実際には、「きれいなコードを書くように努める」より「テストでインラインモックを使わない」のほうが効果的です。詳しいテンプレートは[「CLAUDE.mdの設定方法」](https://ailoot.ai/blog/ja/claude-md-template/)をご覧ください。

2. **検証済みパターンを3～7個含む`examples/`フォルダー。** よく使うパターンごとに1つ、たとえばAPI呼び出し、テストの作成、マイグレーション、エラー処理の例を置きます。Claudeは`examples/`にパターンを見つけると、正確に再現します。例がなければ、作業しながら推測します。

3. **主要な機能向けのPRPドキュメント。** PRPはProduct Requirements Promptの略です。機能ごとに1つのファイルを用意し、コンテキスト、計画、検証、例をまとめます。

4. **セッションをまたいだ長期的な事実を保存するメモリツール。** AnthropicのCookbookでは、Claudeのメモリツールを構造化されたメモの保存場所として実装しています。エージェントが新しいセッションでタスクに戻ると、コーパス全体を読み直すのではなく、まずメモを読みます。

5. **`/compact`と上限の80%での自動コンパクション。** ウィンドウが上限に達するまで待たないでください。設定で自動コンパクションを有効にするか、セッションが堂々巡りになってきたと感じたら自分で`/compact`を実行します。

6. **調査、レビュー、計画にサブエージェントを使う。** 各サブエージェントは独自のコンテキストと範囲を絞ったプロンプトを持ちます。リードClaudeが受け取るのは素材そのものではなく、要約だけです。詳細は[「Claude Codeのサブエージェント」](https://ailoot.ai/blog/ja/claude-code-subagents/)と[「Claude CodeのSkills」](https://ailoot.ai/blog/ja/claude-code-skills-library/)をご覧ください（Skillsは、Claudeが自動的に適用する限定的な専門知識をパッケージ化する方法です）。

7. **あらかじめ読み込むのではなく、必要なときに情報を取得する。** リポジトリ全体をウィンドウに入れないでください。Claude自身に`glob`と`grep`で検索させます。これはClaude Code自体の構成です。

紹介されているプロジェクトでの実践経験に基づく追加ルールは次のとおりです。

- **1つのタスクに1つのウィンドウ。** 作業を終えたら閉じて、新しいウィンドウを開きます。複数の連続したタスクの履歴を蓄積しないでください。
- **新しいウィンドウで最初に使うコマンドのテンプレート。** 毎回同じテキストを使います。「順番に`CLAUDE.md`、タスク領域を読んでください。1行で確認してください。タスクは開始せず、次のメッセージを待ってください。」紹介されているワークフローでは、このテンプレートをスニペットエディターに保存し、1つのホットキーで呼び出します。
- **コンテキストウィンドウが60%を超えたら、新しいものに切り替える。** 途中段階の方法として、Claudeに「隣のチャットが意味を失わずにタスクを引き継げるよう、プロンプトを書いて」と頼み、そのプロンプトをコピーして新しいウィンドウを開きます。
- **AIの間違いはすべて、ルールを追加する理由になる。** メモリファイルに手作業でルールを書かないでください。間違いが起きたときにClaudeへ「それは間違いです。なぜなら……」と伝えれば、「ルール→理由→方法」の規約に従ってルールをファイルに整えます。

## 今後：コンテキストエンジニアリングはどう発展するのか？

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="このセクションの重要なポイント">

重要なポイント

2026年、コンテキストエンジニアリングはテキストベースのMarkdownファイルから、より構造化された形式へと移行しています。エージェントが過去のセッションを一晩かけて再検討するDreaming機能も登場しました。次に来るのはHTML成果物、永続メモリ、プロダクトチーム全体にわたるマルチエージェントのオーケストレーションです。

</div>

現在、この分野が進んでいる方向の1つを紹介します。

**Dreaming—セッションを一晩かけて再検討する。** 2026年5月6日のCode w/ Claude SFで、Anthropicはエージェントが過去のセッションを一晩かけて再検討し、自分のメモを更新する機能を披露しました。構造化されたメモリファイルは、あなたが書き込むときだけでなく、エージェントが蓄積された経験から結論を導くときにも成長するようになりました。

1つの傾向は明らかです。コンテキストエンジニアリングは、単なる「CLAUDE.mdの書き方」ではなく、AIエージェント向けに情報を設計する総合的な分野になりつつあります。プロンプトエンジニアリングは、この分野の初期の段階の1つでした。次に来るのがコンテキストエンジニアリングです。

最初の晩に整える価値がある最低限の内容は、CLAUDE.mdを80～120行に設定し（[ガイドはこちら](https://ailoot.ai/blog/ja/claude-md-template/)）、ビジネス知識の構成を含むフォルダーを作成し、`/compact`の使い方を覚え、[上限の無駄遣いをやめる](https://ailoot.ai/blog/ja/claude-code-token-limits-saving/)ことです。

次に、サブエージェント（[ガイド](https://ailoot.ai/blog/ja/claude-code-subagents/)）と[Skills](https://ailoot.ai/blog/ja/claude-code-skills-library/)を追加し、専門知識を共有コンテキストから専用のスキルへ移します。

<div class="section" role="doc-bibliography" aria-label="出典">

### 出典

- [AIエージェントのための効果的なコンテキストエンジニアリング](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) - Anthropic Applied AI team、29.09.2025。4つのコンテキストエンジニアリング原則をまとめた基本資料。
- [マルチエージェント調査システムの構築方法](https://www.anthropic.com/engineering/multi-agent-research-system) - Anthropic Engineering、13.06.2025。品質+90.2%、トークン15倍という数値の出典。
- [Anthropic Cookbook - ツール使用によるコンテキストエンジニアリング](https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools) - コンパクション、ツール結果の整理、メモリツールの実践的な基本機能。
- [Claude Code Memoryのドキュメント](https://code.claude.com/docs/en/memory) - 簡潔で具体的なプロジェクト指示の案内。引用の目標は200行未満で、80〜120行は筆者の好み。

</div>





[Ailoot](https://ailoot.ai/)について詳しくご覧ください。

## 2026年のコンテキストエンジニアリング：その意味、プロンプトエンジニアリングとの違い、Claude Codeでの活用方法：よくある質問

### CLAUDE.mdの200行は厳密な上限ですか？

いいえ。引用した案内は文脈を節約し指示に従いやすくするための目安です。80〜120行は筆者の実用上の好みです。行数を保証とせず、実タスクで重要なルールを確認してください。

### 初期コンテキストから何を外へ移しますか？

詳細な例、長いツール結果、特定タスクの参考資料を別ファイルへ移します。CLAUDE.mdには短いルールと案内を残し、必要なときに関連箇所を取得してください。


## Ailoot · 企業とそのプロジェクト群

Ailootは、蓄積した運営経験、幅広い顧客基盤、安定したサービス、継続的なKPI管理を基盤としています。

企業とそのプロジェクト群：数百万の顧客、毎月数十億規模の売上。

Ailootはこの運営経験を、お客様の製品、エージェント、アプリケーション、自動化でAI機能を利用するためのAPIアクセスに活かしています。