第9章 アプリの管理画面

この章では、スタジオでアプリを開いたときに使える画面（オーケストレーション・APIアクセス・ログ・モニタリング）を説明します。アプリは「作って終わり」ではなく、公開したあとに「どう使われているか」「答えは正しいか」「消費量は増えていないか」を確認しながら直していきます。この章を読むと、その確認をどの画面で行うかが分かります。

• ノードの配置・接続・設定の操作は第7章で説明します。
• APIの実際の呼び出し方（プログラムからの利用）は第11章で説明します。
• エラーが出たときの対処は第14章で説明します。
• 画面の名称・配置はバージョンや環境により異なることがあります（序章「本書の確認環境」参照）。

9-1. アプリ内の画面切り替え（全体像）

Difyには、性質の異なる2種類のメニューがあります。まずこの区別をつかむと、目的の画面で迷いません。

スタジオでアプリを1つ開くと、そのアプリ専用の画面に切り替わります。アプリ内では、画面左側のメニューで次の4つの画面を行き来します。

図9-1　ワークスペースからアプリを開くと、アプリ専用の4つの画面に切り替わる

補足を2点書きます。

• ワークスペースのメニュー（探索・スタジオ・ナレッジ・ツール）の役割は序章0-3のとおりです。本章では、その中の「スタジオ」から先、アプリを開いた中の画面を扱います。
• アプリ内の画面の名称・並び・数は、アプリの種類やバージョンにより異なることがあります。本書では公式ドキュメントの呼び名（オーケストレーション・APIアクセス・ログ・モニタリング）で説明します。

9-2. オーケストレーション（編集画面）

オーケストレーション は、アプリの中身を編集する画面です。序章0-3と第2章2-4で「編集画面」と呼んでいた画面がこれにあたります。アプリを作成した直後に開くのもこの画面です。

画面の構成は、アプリの種類によって異なります（第2章2-4と同じ2区分です）。

この画面でできることは、大きく次の4つです。

• 編集する：指示文・ノード・設定を変更します。ノードの追加・接続・設定・削除・複製の操作は第7章で説明します。
• 試す：ワークフローでは「テスト実行」、対話型のアプリでは「デバッグとプレビュー」で、公開する前に動きを確かめます（第2章2-6・第7章）。
• 公開する：確認できたら公開の操作を行います。公開の形（Webアプリ・埋め込み・API・MCPサーバー）は第2章2-7のとおりです。
• DSLファイルを書き出す：画面左上の「DSL エクスポート」から、アプリの設計内容をDSLファイル（アプリの設計内容を書き出したファイル）として保存できます。控えの保管や他の環境への持ち出しに使います（詳しくは第12章）。

公開したあとにアプリを直すときも、この画面に戻って編集します。編集した内容は、公開の操作（更新の公開）を行うまで、公開中のアプリには反映されません。

9-3. APIアクセス

APIアクセス は、作ったアプリを外部のシステムから呼び出す窓口（API）として使うための画面です。ここでAPIキー（APIを呼び出すときに本人確認として添える鍵の文字列）を発行・管理します。

たとえば、庁内のポータルサイトや既存の業務システムからDifyのアプリを呼び出したいときに使います。ブラウザでアプリを使うだけなら、この画面を使う必要はありません。

この画面でできることは次のとおりです。

• APIキーの発行と管理（不要になったキーの削除）。APIキーはアプリごとに発行します。
• 接続先（ベースURL）の確認。クラウド版では https://api.dify.ai/v1 です。
• APIでできる操作は、アプリの種類（チャットボット・ワークフローなど）によって構成が異なります。詳しい仕様は公式ドキュメントのAPIリファレンスで確認します。

APIキーを発行する手順は次のとおりです。

前提：アプリを作成済みであること。

1. スタジオで対象のアプリを開きます。
2. 左側のメニューからAPIアクセスの画面を開きます。
3. APIキーを発行する操作を行います（ボタンの名称・配置はバージョンにより異なります）。
4. 発行されたAPIキーを、所属のルールに従って安全な場所に控えます。

完了状態：発行したAPIキーが画面の一覧に表示されている。

APIキーの取り扱いでは、次の点を守ってください。

• APIは、サーバー側（バックエンド）のプログラムからのみ呼び出します。利用者のブラウザで動く画面側のプログラムにAPIキーを埋め込むと、キーを抜き取られて悪用されるおそれがあります（公式ドキュメントの注意事項）。
• APIキーは秘密情報です。メール・チャット・共有ファイルに直接書いて配らないでください。漏れた疑いがあるときは、キーを削除して発行し直します。
• 庁内ネットワークから外部のシステムに接続できるかは環境によります。連携を計画する前に、情報担当部署に確認してください（序章0-5と同じ注意です）。

APIを実際に呼び出す手順（リクエストの書き方・試し方）は第11章で説明します。

9-4. ログ

ログ は、アプリの利用記録を1件ずつ確認する画面です。誰が・いつ・何を入力し、アプリが何を返したかが残るため、公開後の点検はこの画面が起点になります。

記録される単位は、アプリの種類によって異なります。

• チャットボットなどの対話型のアプリとテキストジェネレーターは、利用者とのやり取り（会話）が記録されます。
• ワークフローは、1回ごとの実行が記録されます。

一覧に表示される主な項目は次のとおりです。

ワークフローの実行記録では、このほかに開始時刻・実行の成否（ステータス）・実行時間・トークン数が一覧で確認できます。

一覧から1件を開くと、さらに詳しい内容を確認できます。

• 質問と答えの全文
• トークン消費と応答時間
• 処理の過程（どのノードに何が入力され、何が出力されたかの記録。ワークフロー・チャットフローの場合）

公開後に答えの中身を確かめる手順は次のとおりです。

前提：アプリを公開済みで、利用が始まっていること。

1. スタジオで対象のアプリを開きます。
2. 左側のメニューからログの画面を開きます。
3. 一覧から確認したい記録を選んで開きます。
4. 質問と答えの全文を読み、答えが正しいか・意図どおりかを確認します。あわせてトークン消費・応答時間も確認します。
5. 直したい答えが見つかったら、原因に応じてオーケストレーションで指示文やノードを修正します（エラーが原因の場合の切り分けは第14章）。

完了状態：確認した記録について、答えの内容・トークン消費・応答時間を把握できている。

ログの使いどころと注意は次のとおりです。

• 誤った答え・分かりにくい答えを見つけて、修正のきっかけにします。利用者の評価（ユーザーレート）が低い記録から確認すると効率的です。
• ログの答えには 注釈 を追加できます。質問に対する改善済みの回答を登録しておく機能です。
• ログには利用者が入力した文がそのまま残ります。閲覧・共有は、所属の個人情報の取り扱いルールに従ってください。

9-5. モニタリング

モニタリング は、アプリの利用状況の集計を確認する画面です。ログが「1件ずつの中身」を見る画面であるのに対し、モニタリングは「全体の傾向」をグラフと数値で見ます。公式ドキュメントではこの集計画面をダッシュボードと呼びます。

表示される主な指標は次の4つです。

• 指標名の画面上の表記は、バージョン・言語設定により異なることがあります（公式ドキュメントでは英語名で示されています）。
• 期間の切り替え（時間セレクター）で、日ごと・期間ごとの推移を確認できます。
• 外部の分析サービスにつないでさらに詳しく分析する機能（アプリのパフォーマンスのトレース）もありますが、本書では扱いません。

運用中の定期確認の手順は次のとおりです（例：月に1回）。

前提：アプリを公開済みで、利用が始まっていること。

1. スタジオで対象のアプリを開きます。
2. 左側のメニューからモニタリングの画面を開きます。
3. 期間を確認したい範囲（例：直近1か月）に切り替えます。
4. メッセージ総数とアクティブユーザー数で、利用が続いているか・増えているかを確認します。
5. トークン使用量で、消費量が想定の範囲に収まっているかを確認します。急に増えているときは、ログで使われ方を確認します。

完了状態：対象期間の利用件数・利用者数・トークン使用量を把握し、必要ならログでの確認事項を書き出せている。

まとめ：4つの画面の使い分け

公開後は「モニタリングで全体を見る → 気になる点をログで1件ずつ確かめる → オーケストレーションで直す」という順で確認すると、無理なく続けられます。

次の章では、オーケストレーションの画面で使うノードの種類を1つずつ説明します（第10章「ノードの種類」・本マニュアル）。

出典一覧

本章の記述の根拠です（いずれも確認日：2026-08-14。「APIアクセス」行と「モニタリング」行の追記は2026-08-17）。