AI_Dify

2026年2月7日

Difyで構築した医療AIの「暴走」をどう防ぐ？安全設計を実現する3つの運用ポイント

大規模言語モデル（LLM）の進化は、Difyのようなノーコードプラットフォームを通じ、医療現場のDXを加速させています。しかし、その利便性の裏側には、AIが事実と異なる情報を自信満々に生成する「ハルシネーション」（暴走）という、特に医療分野では致命的なリスクが潜んでいます。誤った診断や治療方針につながる情報は、患者の安全に直結するため、AIの安全設計は最優先事項です。

本記事は、Difyを用いて医療AIを構築・運用する担当者向けに、ハルシネーションや不適切な応答といった「暴走」を未然に防ぎ、信頼性を確保するための、実践的な3つの運用ポイントを解説します。これらの対策を徹底することで、医療AIを安全な「臨床支援ツール」へと進化させることができます。

医療AIの安全設計を表す、RAG、ガードレール、人によるチェックの3層構造の概念図

1. 医療AIの暴走を防ぐ3つの運用ポイント

医療AIにおける「暴走」とは、単なる誤答ではなく、患者の安全や治療方針に影響を及ぼす誤情報を生成することです。これを防ぐためには、技術的な対策と、それを支える運用体制の確立が不可欠です。DifyのようなLLMプラットフォームを活用する上で、特に重要な運用ポイントは以下の3点に集約されます。

厳格なRAG設計と信頼できる知識ベースの構築: LLMの弱点である知識不足を、正確な医療データで補完するファクトベースの徹底。
AIガードレールとプロンプトエンジニアリングの徹底: 不適切な質問や出力そのものをシステムレベルで制御し、倫理的な逸脱を防ぐ。
LLMOpsとHuman-in-the-Loop（HITL）による継続的改善: 人間による最終確認と、利用状況に基づいたシステムの継続的な精度向上。

これら3つのポイントは、単独ではなく多層防御（Defense in Depth）として機能させることで、ハルシネーションの発生率を実務に支障がないレベルまで大幅に抑制することが可能です。特に医療・金融・法務といったクリティカルな領域では、ハルシネーションが「致命的な問題」につながるため、これらの運用体制の確立は不可欠です。

2. 運用ポイント1: 厳格なRAG設計と信頼できる知識ベースの構築

Difyで医療AIを構築する際の最も有効な暴走対策が、RAG（Retrieval-Augmented Generation：検索拡張生成）の厳格な設計です。LLMは確率に基づいて次の単語を予測するため、学習データにない情報や古い情報に対して「もっともらしい嘘」（ハルシネーション）をつく傾向があります。RAGはこの問題を解決し、LLMが回答を生成する前に、外部の信頼できる情報源（電子カルテ、最新の臨床ガイドライン、院内マニュアルなど）から関連データを検索・参照することを強制します。

このRAGを機能させる上で重要なのは、単にデータを登録するだけでなく、「知識ベース」の品質を厳格に管理することです。RAGの導入効果は、検索エンジンの性能によって大きく左右され、検証データではツールによって回答の正答率に約40%もの開きが出たというデータもあります。 Difyでは、知識ベースのチャンキング（分割）方法や埋め込みモデルの選定を最適化し、LLMに「わからない場合は根拠を示さない」または「わからないと答える」よう明確に指示することが、正確性を約70%向上させる鍵となります。

💡 ポイント: RAGのファクトチェック機構

RAGによって回答の根拠となった情報（ソースドキュメント）を必ず提示させ、ユーザー（医療従事者）が情報の正確性を確認できる「透明性」を確保することが、医療AIの信頼性を高める上で最も重要です。

【出典】

AIの設計・開発・運用をガイドラインでサポート

(www.aist.go.jp)

3. 運用ポイント2: AIガードレールとプロンプトエンジニアリングの徹底

項目	セルフホスト（推奨）	クラウドホスト（要検討）
データ機密性	院内閉域網で完結。最高レベルの機密性を確保。	データ転送・保存時にセキュリティ対策が必須。
コンプライアンス	厚労省ガイドライン準拠が容易。	外部サービスのセキュリティ監査が必須。
カスタマイズ性	LLMやRAGの構成を自由に調整可能。	サービス提供者の制約を受ける。

2026年2月6日

Difyエージェントの出力制御：医療現場で信頼されるAI運用のための安全設計ロードマップ

AI_Dify, コラム一覧

大規模言語モデル（LLM）を活用したAIエージェントは、医療現場における業務効率化や診断支援の可能性を秘めています。しかし、その「ハルシネーション」（もっともらしい誤情報生成）のリスクは、患者の命に関わる医療分野において最大の課題です。特に、Difyのようなローコードプラットフォームでエージェントを構築する際、いかにしてAIの出力を厳格に制御し、信頼性を担保するかが、実運用への鍵となります。本記事では、プロフェッショナルなメディカル・テクニカルライターの視点から、Difyエージェントを医療現場で安全に運用するための「出力制御ロードマップ」を、具体的な技術ステップと法的・倫理的課題への対応を含めて解説します。このロードマップに従うことで、生成AIの恩恵を最大限に享受しつつ、医療安全基準を満たすAIシステムの設計が可能になります。

1. 医療AIにおける「ハルシネーション」の深刻なリスク

LLMが生成する誤情報、すなわちハルシネーションは、医療分野において致命的な結果を招く可能性があります。例えば、LLMが医療指示の要約を作成する際、元の文書では「5mg錠剤を1日1回摂取」とされていたにもかかわらず、「50mg錠剤を1日3回摂取」という誤った指示を生成する事例が報告されています。これは、患者に本来の用量の30倍の薬品を摂取させることになる、極めて高リスクなハルシネーションです。

また、AIが生成する情報は一見すると流暢で自信ありげに見えるため、専門家でも見抜くことが困難な場合があります。ある研究では、ChatGPT-3.5が精神医学関連の論文を引用した際、約55%が架空の論文であったことが判明しており、著者名や掲載誌まで「それらしく」捏造されていました。このようなリスクを回避するためには、単一の対策ではなく、Difyエージェントの設計段階から多層的な出力制御を組み込むことが不可欠です。この高いリスクを背景に、医療AIの導入においては、最終的な判断を必ず人間が行う「Human-in-the-Loop」の原則が必須とされています。

【出典】

令和6年版情報通信白書｜生成AIが抱える課題

(www.soumu.go.jp)

2. 結論：信頼されるAI運用のための多層的出力制御ロードマップ

医療現場でDifyエージェントを安全に運用するには、単なるプロンプト調整だけでは不十分であり、「入力→処理→出力」の各段階で厳格な制御をかける多層防御の仕組みが必要です。これは、厚生労働省が定める「医療デジタルデータのAI研究開発等への利活用に係るガイドライン」など、日本の医療AI規制環境に準拠するための基本戦略となります。

このロードマップは、以下の3つのフェーズで構成されます。各フェーズは前のフェーズのリスクを補完し、最終的な出力の信頼性を飛躍的に高めることを目的としています。約90%の医療リスクは、このロードマップの「情報源の限定」と「最終検証」のフェーズで効果的に低減可能となります。

フェーズ	Dify機能	制御の目的	リスク低減率（目標）
初期安全性の確保	プロンプトエンジニアリング	役割と制約の明確化	約30%
情報源とアクションの限定	RAG / Tool Calling	ハルシネーションの構造的排除	約60%
最終出力の検証	後処理 / 外部フィルタ	ガイドライン・倫理的適合性の確認	約90%以上

💡 ポイント

医療AIの安全設計は「多層防御」が大原則です。Difyのプロンプト、RAG、Tool Callingを組み合わせ、さらに外部の検証機構を最終フィルタとして機能させることで、単一の技術に依存するリスクを回避します。

3. ステップ1: プロンプトエンジニアリングによる初期安全性の確保

2026年1月25日

Difyでつくる論⽂仕分けアプリ part4: Difyと GASの連携

AI_Dify, コラム一覧

1. はじめに
2. Part 3からの流れ
3. Dify側の保存フロー
4. Google Apps Scriptとは？
5. GASの作り⽅とデプロイ⼿順
6. 動作確認とプレビュー
7. まとめ

1. はじめに

本記事は、Difyのチャットワークフローを使ってPubMed論⽂の検索‧翻訳‧要約を⾃動化するシリーズのPart 4です。

これまでの復習:

Part 0: ワークフローの全体像とPubMed APIの基礎
Part 1: ⾃然⾔語クエリからE-SearchでPMIDを取得
Part 2: E-Fetch / E-Summaryで詳細データを取得し、XML/JSONをパース
Part 3: LLMでタイトル翻訳‧要約‧優先度判定を⾏い、CSVを⽣成

Part 4（本記事）では、⽣成したCSVデータをGoogle Apps Script（GAS）に送信してスプレッドシートへ保存する処理を解説します。GASの基礎知識から実装⼿順、コードの詳細解説まで、⼀通り理解できるように構成しています。これにより、ユーザーはスプレッドシートのURLを受け取り、結果を即座に確認できるようになります。

シリーズ構成

Part0: 全体像とPubMed API基礎
Part 1: パラメータ抽出とE-Search編
Part 2: E-Fetchとデータパース編
Part 3: AI処理‧データ整形編
Part4（本記事）: データ保存とGAS連携編

2. Part 3からの流れ

Part 3で⽣成したCSVは以下の形式でした。

"PMID","Priority","Title_JP","Summary","Title_EN","Authors","Journal","Year","DOI","MeSH_Keywords","URL","m ain_author_affiliation","research_area","publication_types","population"
"12345678","HIGH","糖尿病におけるインスリン療法の効果","本研究は、2型糖尿病患者におけるインスリン療法の
有効性を検証した。...","Effect of Insulin Therapy in Type 2 Diabetes","John Smith, Jane Doe","Diabetes Resear ch","2024","10.1234/example","diabetes, insulin, therapy","<https://pubmed.ncbi.nlm.nih.gov/12345678/","Uni
versity> of Tokyo","内分泌","Randomized Controlled Trial","2型糖尿病患者（成⼈）"

このCSV⽂字列をGASに送信してスプレッドシートに保存します。

3. Dify側の保存フロー

3-1. GASに追記（HTTP Request）

以下の画像ではURL保護のためにグレーアウトさせていますが、本記事の後半で設定方法を解説していますので順に読み進めて問題ありません。

項⽬	設定値
メソッド	POST
URL	URLは後ほどGAS側の設定をした後に発⾏されるものをコピーして使います。ここでは⼀旦スキップで⼤丈夫です。
ヘッダー	Content-Type:application/json

このノードでは、DifyからGoogle Apps Script（GAS）のWebアプリを呼び出して、CSVデータをスプレッドシートに保存します。

リクエスト例

{ 
  "csv_string": "{{#csv_string#}}"
}

Part3で作成したCSV⽣成ノードからの csv_string を、JSON形式でGASに送信します。

レスポンス例

{ 
  "status": "success", 
  "message": "Data appended successfully", 
  "spreadsheet_url": "<https://docs.google.com/spreadsheets/d/>..."
}

GASからは、処理結果とスプレッドシートのURLが返されます。

3-2.スプレッドシートURLを抽出

import json

def main(body: str): 
  if not body: 
    raise ValueError("invalid parameter") 
  result = json.loads(body) 
  return {"spreadsheet_url": result["spreadsheet_url"]}

GASからのレスポンスから、スプレッドシートのURLを抽出します。

3-3. Answerノード

応答：{{#spreadsheet_url#}}
出⼒: スプレッドシートへのリンクのみをシンプルに表⽰

ここまででDify側のフローは完成しますが、実際に動作させるためには、GASのWebアプリを作成‧デプロイする必要があります。以下、GASの基礎から実装⼿順まで順を追って解説します。

4. Google Apps Scriptとは？

4-1. Google Apps Scriptの概要

Google Apps Script（GAS）はGoogleが提供するクラウドベースのJavaScript実⾏環境で、Google Workspace（スプレッドシート、ドライブ、メール、カレンダーなど）を⾃動化‧拡張するために設計されたプラットフォームです。ブラウザ上のエディタだけで完結し、インフラ構築やサーバ管理なしでスクリプトを動かせるため、「ちょっとした業務⾃動化」から「⼩さな業務システム」までを素早く⽴ち上げられる点が特徴です。

4-2. Google Apps Scriptの主な特徴

特徴	説明
無料で利⽤可能	Googleアカウントさえあれば、追加費⽤なしで利⽤できます。Google Workspace有償プランでも追加課⾦なく使えます。
Google Workspaceとの親和性	スプレッドシート、ドライブ、メール、カレンダーなどとネイティブに連携でき、専⽤のAPIが多数⽤意されています。
Webアプリとして公開可能	HTTPリクエストで呼び出せるWebエンドポイントを数クリックで公開でき、今回のようにDifyから直接叩くことができます。
定期実⾏が可能	「毎⽇9時」「毎週⽉曜」のような時間ベースのトリガーや、フォーム送信などイベントベースのトリガーを簡単に設定できます。

GASがあると何が嬉しい？

GASは⾯倒な⼿作業を⾃動化するために⽤いられることが多いです。

例えば、本記事シリーズで解説している論⽂仕分けアプリでは、Difyが作成するcsvデータをSpreadsheet上に転記する作業をGASに任せます。そうすることで、Dify上で知りたいことを⼊⼒するだけで、Spreadsheet上にどんどん論⽂のリストが溜まっていく仕組みを構築することができます。

GASとDify連携で広がる可能性

Dify単体でも様々な外部ツールと連携して「⽣成AIによる要約や分類」「業務の⾃動化」を⾏うことができます。しかし、GASを⽤いてGmailやSpreadsheetと連携させることで、使い慣れたサービス上でDifyのパワーを発揮することが可能です。

例えば、

アポ⾒込みのある顧客についてのシートに対して、DifyとGASを⽤いて顧客情報をネットから付与していく
安全性情報のスクリーニングを⾃動化して、スプレッドシートに結果をまとめる。
製薬企業が出した最新のニュースをDifyで要約しながらGmailでまとめてメルマガのように運⽤する

など、様々な使い⽅が可能になります

5. GASの作り⽅とデプロイ⼿順

ここからは、実際にGASを作成してデプロイする⼿順を、ステップバイステップで解説します。

5-1. Google Apps Scriptエディタの開き⽅

Googleスプレッドシートを開く
- 新しいスプレッドシートを作成するか、既存のスプレッドシートを開きます
- このスプレッドシートに、論⽂データが保存されます
スクリプトエディタを開く
- メニューから「拡張機能」→「Apps Script」を選択します

スクリプトエディタが開くと、ブラウザ上にコードエディタが表⽰され、ここにコードを書き込んでいきます。

5-2. コードの記述

スクリプトエディタに、以下のコードをコピー&ペーストします。

function doPost(e){
  var result = {status:'success',message:'Data appended successfully'};

  try{
  var csvString = "";
  try{
    var postData = JSON.parse(e.postData.contents);
    csvString=postData.csv_string||postData.csv_output||postData.output;
  }catch(jsonError){
    csvString=e.postData.contents;
  }

  if (!csvString) {
    throw new Error("No CSV data found.");
  }

  var csvData = Utilities.parseCsv(csvString); 
  if (csvData.length < 2) {
    return createJsonResponse({ status: 'skipped', message: 'No content rows found in CSV' });
  }

  var csvHeaders = csvData.shift(); 
  var csvBody = csvData;

  var ss = SpreadsheetApp.getActiveSpreadsheet(); 
  var sheet = ss.getActiveSheet(); 
  result.spreadsheet_url = ss.getUrl();

  var lastRow = sheet.getLastRow();

  if (lastRow === 0) {
    sheet.appendRow(csvHeaders);   
    if (csvBody.length > 0) {
      sheet.getRange(2, 1, csvBody.length, csvBody[0].length).setValues(csvBody);
    }
  } else {
    var sheetHeaders = sheet.getRange(1, 1, 1, sheet.getLastColumn()).getValues()[0]; 
    var csvHeaderMap = {};
    csvHeaders.forEach(function(header, index) { 
      csvHeaderMap[header] = index;
    });

    var outputRows = csvBody.map(function(row) { 
      return sheetHeaders.map(function(sheetColName) { 
        var csvColIndex = csvHeaderMap[sheetColName];  
        return csvColIndex !== undefined?row[csvColIndex]:"";
      });
    });

    if (outputRows.length > 0) {
      sheet.getRange(lastRow + 1, 1, outputRows.length, outputRows[0].length).setValues(outputRows);
    }
  }

  } catch (error) { 
    result.status = 'error';
    result.message = error.toString();
  }

  return createJsonResponse(result);
}

function createJsonResponse(data) {
  return ContentService.createTextOutput(JSON.stringify(data))
  .setMimeType(ContentService.MimeType.JSON);
}

5-3. Webアプリとしてデプロイする⽅法

ステップ1: デプロイメニューを開く

コードを記述したら、次はWebアプリとしてデプロイします。

スクリプトエディタの右上にある「デプロイ」ボタンをクリック
「新しいデプロイ」を選択

ステップ2: デプロイ設定

項⽬	設定値
種類の選択	ウェブアプリ
説明	任意（例：PubMed論⽂取り込みAPI）
次のユーザーとして実⾏	⾃分
アクセスできるユーザー	全員（外部から呼び出すため）

重要: 「アクセスできるユーザー」を「全員」に設定しないと、Difyから呼び出せません。

本ブログシリーズでは、簡易化のために「アクセスできるユーザー = 全員」にしました。しかし社内で実運用を行う場合には、全員がアクセスできる状態は許容できません。
簡易的な仕組みでは、呼び出し側（今回の場合Dify）と受け取り側（GAS）にのみ認証用の鍵をセットしておき、簡単な認証を行う方法があります。検証のために作成および公開したGASアプリなどはURLが外部に漏れないように注意しましょう。

ステップ3: デプロイ実⾏

「デプロイ」をクリック
初回実⾏時は、Googleアカウントでの承認フローが表⽰されます

「アクセスを承認」をクリック
必要に応じて、Googleアカウントの認証を完了

ステップ4: WebアプリのURLを取得

デプロイが完了すると、WebアプリのURLが表⽰されます。

<https://script.google.com/macros/s/xxxxxxxxxxxx/exec>

このURLをコピーしておきます。このURLが、DifyワークフローからPOSTする際のエンドポイントになります。

5-4. DifyでURLを設定

セクション3-2で解説した「GASに追記」ノード（HTTPリクエストノード）のURLに、取得したWebアプリのURLを設定します。

これで、Dify → GAS → スプレッドシートというパイプラインが完成します。

5-5. デプロイ時の注意点

項⽬	注意点
アクセス権限	外部から呼び出す場合は「全員」に設定。初回実⾏時、Googleアカウントの認証が必要な場合あり
コードの更新	コードを更新した場合は、新しいバージョンとしてデプロイが必要。「デプロイを管理」から新しいバージョンをデプロイ

6. 動作確認とプレビュー

GASのデプロイとDifyでのURL設定が完了したら、ワークフロー全体を動作確認してみましょう。

6-1. ワークフロー全体の動作確認

Difyのチャット画⾯で、⾃然⾔語で論⽂検索クエリを⼊⼒
- 例：「糖尿病のインスリン療法に関する2020年以降のRCT」
ワークフローが実⾏され、以下の流れで処理が進みます
- パラメータ抽出 → E-Search → E-Fetch → LLM処理 → CSV⽣成 → GAS送信 → スプレッドシート保存
結果として、スプレッドシートのURLが返されます

7. まとめ

本記事（Part 4）では、Difyで⽣成したCSVデータをGoogle Apps Script（GAS）に送信してスプレッドシートへ保存する処理を、GASの基礎から実装⼿順、コード解説まで⼀通り解説しました。

本記事で実現したこと

Dify側の保存フロー: CSV⽣成ノードから直接GASに送信
GASの基礎知識: GASとは何か、その特徴とライフサイエンス業界での活⽤メリット
GASの実装⼿順: エディタの開き⽅からWebアプリのデプロイまで
GASコードの詳細解説: リクエスト受信からスプレッドシート保存までの処理フロー

Dify×GAS連携のポイント

ポイント	説明
シンプルな連携	DifyからHTTP POSTでGASを呼び出すだけで、データの永続化が実現できる
直接的なデータフロー	CSV⽣成ノードから直接GASに送信する単⼀経路のため、シンプルで理解しやすい
柔軟な拡張	GAS側で通知‧定期実⾏‧データ分析などの機能を追加できる
コスト効率	既存のGoogle Workspace環境を活⽤し、追加コストを抑えられる

次のステップ

基本的な連携が完成したら、以下のような拡張も可能です。

メール通知: 重要な論⽂が追加されたら、関係者にメール通知
定期実⾏: 毎⽇‧毎週など、定期的に論⽂を⾃動収集
複数シートへの振り分け: 研究テーマ別にシートを分けて管理
データ分析‧可視化: グラフ作成やレポート⾃動⽣成

DifyとGASを組み合わせることで、ライフサイエンス‧製薬業界の多様な課題に対応し、業務効率化とデータ管理の強化が期待できます。

シリーズ構成

Part0: 全体像とPubMed API基礎
Part 1: パラメータ抽出とE-Search編
Part 2: E-Fetchとデータパース編
Part 3: AI処理‧データ整形編
Part4（本記事）: データ保存とGAS連携編

ヘルツレーベンでは、ライフサイエンス業界に特化したDX・自動化支援を提供しています。
PubMedや学術情報の自動収集をはじめ、Slack・Gmailなどを活用したナレッジ共有の仕組みまで、実務に直結するワークフローを設計・導入いたします。

提供サービスの例

製薬・医療機器業界での提案活動や調査業務の自動化支援
アカデミアや研究者向けの文献レビュー・情報共有フローの最適化
医療従事者のキャリア開発を支援するリスキリングプログラム

👉 ご興味をお持ちの方はぜひお気軽にお問い合わせください。
お問い合わせフォームはこちら

監修者　株式会社ヘルツレーベン代表木下渉

株式会社ヘルツレーベン代表取締役／医療・製薬・医療機器領域に特化したDXコンサルタント／
横浜市立大学大学院ヘルスデータサイエンス研究科修了

製薬・医療機器企業向けのデータ利活用支援、提案代行、営業戦略支援を中心に、医療従事者向けのデジタルスキル教育にも取り組む。AI・データ活用の専門家として、企業研修、プロジェクトPMO、生成AI導入支援など幅広く活動中

2026年1月17日

Difyでつくる論⽂仕分けアプリ　　　　　　　　　　　　　　　　　　　　　　　　Part3: LLM処理‧データ保存編

AI_Dify, コラム一覧

1. はじめに
2. Part 2からの流れ
3. 各ノードの詳細解説
4. まとめ

1. はじめに

本記事は、Difyのチャットワークフローを使って、PubMed論⽂の検索‧翻訳‧要約を⾃動化するシステムを構築するシリーズのPart 3です。

Part 2の復習: 前回の記事では、E-Fetchで論⽂詳細データを取得し、XMLをパースして構造化データを作るところまで解説しました。具体的には、以下のノードを実装しました。

E-Fetch（XML形式で論⽂詳細データを取得）
XMLパース（PythonでXMLを解析し、構造化データに変換）

本記事（Part 3）では、取得した論⽂データに対してLLMで翻訳‧要約‧優先度判定を⾏い、CSV形式に整形する処理を詳しく解説します。この部分は、ワークフローの核⼼となるAI処理部分です。

シリーズ構成

Part0: 全体像とPubMed API基礎
Part 1: 検索・データ取得編
Part 2: AI処理・データ整形編
Part 3（本記事）: LLM処理・データ保存編
Part4: DifyとGAS連携で実現する可能性

2. ワークフローの位置付け

Part 2で取得したデータは、以下のような構造になっています。

E-Fetchを使った場合

{ 
  "parsed_result": [ 
  { 
    "pmid": "12345678", 
    "title": "Effect of Insulin Therapy in Type 2 Diabetes",
    "abstract": "[Background] Type 2 diabetes...", 
    "author": ["John Smith", "Jane Doe"], 
    "journal": "Diabetes Research", 
    "year": "2024", 
    "doi": "10.1234/example", 
    "keywords": ["diabetes", "insulin", "therapy"] 
  } 
  ]
}

本記事では、E-Fetchで取得した論⽂データに対して、以下の処理を⾏います。

イテレーションで各論⽂を一つずつ処理
LLMで各論⽂のタイトル翻訳・要約・優先度判定・研究領域抽出・対象抽出
元データとAI分析結果をマージしてCSV⽣成

3. 各ノードの詳細解説

3-1. イテレーション（Iteration）

パースされた論⽂データの配列をループ処理し、各論⽂に対してLLMによる翻訳‧要約‧優先度判定を⾏うノードです。

イテレーションとは？

DifyのIterationノードは、リストの要素に対して同じ処理を繰り返すために使います。

たとえば、URLリストや論⽂リスト（論⽂1,論⽂2,論⽂3…）の⼀つ⼀つに同じAI処理を適⽤したいときに便利です。このノードは、プログラミングのfor⽂のように、リストのすべての項⽬を順に処理し、結果をまとめて出⼒します。

設定内容

項⽬	設定値
入力変数	{{parsed_result}}
出力変数	{{text}} （後で説明するLLMノードを先に配置すると選択できるようになります）
エラーハンドリング	エラー時は終了
出力をフラット化	true

処理の流れ

⼊⼒: XMLパースノードから parsed_result （論⽂データの配列）を受け取る
ループ: 各論⽂データを1件ずつ処理
出⼒: LLMの出⼒を配列として集約

3-2.LLM（イテレーション内側のノードです）

各論⽂に対して、タイトルの⽇本語翻訳、アブストラクトの要約、優先度判定を⾏うLLMノードです。イテレーション内に配置されており、各論⽂ごとに個別に処理されます。
イテレーションの中で、LLMノードを配置することで、実行するたびに各論文データに対して、一つずつLLMが実行されます。

プロンプトテンプレート

あなたは医学論文の分析と翻訳を行う専門AIアシスタントです。
ユーザーから提供された「論文リスト」と「検索意図（質問）」に基づき、各論文の情報を日本語で構造化して抽出してください。

### ユーザーの検索意図（質問）
{{#sys.query#}}

### タスク
提供された論文について、以下の処理を行ってください。

Title Translation
論文タイトルを自然で簡潔な日本語に翻訳してください。

Summarization
アブストラクトの内容を100文字以上200文字以内の日本語で要約してください。
「目的」「方法」「結果」「結論」の流れを意識して記述してください。
ユーザーの質問に対する「答え」や示唆が含まれているかに注意してください。

Priority Assessment
ユーザーの質問に対するその論文の重要度を3段階で判定してください。
HIGH: 質問の意図と高いレベルで一致し、かつRCT、メタアナリシス、システマティックレビューなど高いエビデンスレベル、または重要な新知見を含む。
MID: 質問と関連はあるが一部が周辺的、または観察研究・症例報告などエビデンスレベルが限定的。
LOW: 質問の意図と大きく異なる、対象が全く異なる（例：動物実験のみ）、または臨床的意義が小さい。

Research Area（研究領域）の抽出
論文のタイトル・アブストラクト・MeSH用語などから、主要な疾患領域・診療科・トピックを1〜3個程度、日本語で要約してください。
例：Oncology, Cardiovascular, Endocrinology, Psychiatry, Neurology, Infectious disease などを、日本語で「腫瘍学」「循環器」「内分泌」「精神科」「神経内科」「感染症」などと表現する。できるだけ専門領域名として通用する粒度で簡潔に記述してください。

Population（対象）の抽出
研究の対象となっている集団を日本語で要約してください。
年齢層（成人/高齢者/小児/新生児 など）
患者群（例：2型糖尿病患者、心不全患者、健常成人 など）
動物実験・細胞実験のみの場合はその旨を明記してください（例：「マウスモデル」「培養細胞」など）。

### 入力データ（論文リスト）
{{#item#}}

プロンプト設計のポイント

検索意図の活⽤: {{#sys.query#}} でユーザーの検索クエリを参照し、要約や優先度判定の基準として使⽤
構造化されたタスク: 5つの明確なタスク（翻訳、要約、優先度判定、研究領域抽出、対象抽出）を定義
優先度判定の基準: HIGH/MID/LOWの判定基準を明確に定義し、⼀貫性のある判定を実現
研究領域と対象の抽出: 論⽂の分類と検索に役⽴つ追加情報を抽出

構造化出⼒（Structured Output）

LLMの出⼒を構造化するため「構造化出⼒」機能を使⽤しています。
※構造化出力はAIのモデルによってサポートされていない場合があります。うまくいかない場合はバージョンを変えて試してみてください（gpt-4o-miniでは動作確認済み）。

フィールド名	型	説明
title_jp	string	論⽂の⽇本語タイトル
summary	string	要約（100〜200⽂字程度）
priority	string	重要度（HIGH, MID, LOW）
research_area	array[string]	研究領域（1〜3個程度、⽇本語）
population	string	対象（年齢層‧患者群‧実験モデルなど）

LLMによってこれらのラベルが自動的に付与されます。

出⼒例

各論⽂に対して以下のJSON形式で出⼒されます。

{ 
  "title_jp": "糖尿病におけるインスリン療法の効果", 
  "summary": "本研究は、2型糖尿病患者におけるインスリン療法の有効性を検証した。無作為化比較試験により、インスリン療法群では血糖コントロールが有意に改善し、HbA1cが平均1.2%低下した。結論として、インスリン療法は2型糖尿病の効果的な治療選択肢であることが示された。", 
  "priority": "HIGH", 
  "research_area": ["内分泌", "糖尿病"], 
  "population": "2型糖尿病患者（成人）"
}

3-3. DB登録⽤データの作成（Codeノード）

元の論⽂データ（XMLパース結果）とAI分析結果（LLM出⼒）をマージし、CSV形式に変換するノードです。

先ほど作成したLLMによる追加データとPubMed APIから取得したデータを統合して、一つの行データとして扱えるようにします。

⼊⼒変数

変数名	ソース	型
original_list	XMLパースノード	array[object]
ai_results_list	イテレーションノード	array[string]

CSVカラム構成

カラム名	説明	データソース
PMID	PubMed ID	元データ
Priority	重要度	AI分析結果
Title_JP	⽇本語タイトル	AI分析結果
Summary	要約	AI分析結果
Title_EN	英語タイトル	元データ
Authors	著者リスト	元データ
Journal	雑誌名	元データ
Year	公開年	元データ
DOI	DOI	元データ
MeSH_Keywords	MeSH⽤語とキーワード	元データ
URL	PubMed URL	⽣成（ https://pubmed.ncbi.nlm.nih.gov/{pmid}/ ）
main_author_affiliation	第⼀著者の所属機関	元データ
research_area	研究領域	AI分析結果
publication_types	論⽂タイプ	元データ
population	対象	AI分析結果

コード詳細

以下はコピペでコードノードに貼り付けるだけで大丈夫です。
コードが動かない時には、「入力変数」「出力変数」の名前やデータ型が正しいかを確認してください。

import json

def main(original_list: list, ai_results_list: list): 
  headers = [ 
    "PMID", 
    "Priority", 
    "Title_JP", 
    "Summary", 
    "Title_EN", 
    "Authors", 
    "Journal", 
    "Year", 
    "DOI", 
    "MeSH_Keywords", 
    "URL", 
    "main_author_affiliation", 
    "research_area", 
    "publication_types", 
    "population" 
  ] 

  csv_rows = [",".join(['"' + h + '"' for h in headers])] 

  for i, original in enumerate(original_list): 
    ai_item = ai_results_list[i] if i < len(ai_results_list) else "{}"

    ai_data = {} 
    try: 
      if isinstance(ai_item, dict): 
        ai_data = ai_item 
      else: 
        clean_json = str(ai_item).replace('```json', '').replace('```', '').strip() 
        ai_data = json.loads(clean_json) 
    except: 
      ai_data = {} 

    row_data = {} 

    pmid = original.get('pmid', '') 
    row_data["PMID"] = pmid 
    row_data["Title_EN"] = original.get('title', '') 
    auths = original.get('authors', original.get('author', [])) 
    row_data["Authors"] = ", ".join(auths) if isinstance(auths, list) else str(auths) 
    row_data["Journal"] = original.get('journal', '')
    row_data["Year"] = original.get('year', '') 
    row_data["DOI"] = original.get('doi', '') 
    row_data["main_author_affiliation"] = original.get('main_author_affiliation','') 
    row_data["publication_types"] = original.get('publication_types','')[0].replace('[','').replace(']','') if original.get('publication_types') else '' 

    kws = original.get('MeSH_Keywords', original.get('keyword', [])) 
    row_data["MeSH_Keywords"] = ", ".join(kws) if isinstance(kws, list) else str(kws) 

    if pmid: 
      row_data["URL"] = f"<https://pubmed.ncbi.nlm.nih.gov/{pmid}/>" 
    else: 
      row_data["URL"] = "" 

    # LLM generated columns 
    row_data["Title_JP"] = ai_data.get('title_jp', '') 
    row_data["Summary"] = ai_data.get('summary', '') 
    row_data["Priority"] = ai_data.get('priority','') 
    research_area_list = ai_data.get('research_area', []) 
    if research_area_list and len(research_area_list) > 0: 
      row_data["research_area"] = research_area_list[0].replace('[','').replace(']','') if isinstance(research_area_list[0], str) else str(research_area_list[0]) 
    else: 
      row_data["research_area"] = '' 
    row_data["population"] = ai_data.get('population','')

    csv_row = [] 
    for col in headers: 
      val = row_data.get(col, "") 
      val_escaped = str(val).replace('"', '""') 
      csv_row.append(f'"{val_escaped}"') 

    csv_rows.append(",".join(csv_row)) 

  final_csv = "\\n".join(csv_rows) 

  return { 
    "csv_string": final_csv
  }

処理の流れ

ヘッダー⾏の⽣成: CSVのヘッダー⾏を作成
ループ処理: 元データとAI分析結果を1件ずつ処理
AI分析結果のパース: LLMの出⼒をJSONとして解析（エラーハンドリング付き）
データマージ: 元データとAI分析結果を統合
CSV⾏の⽣成: 各フィールドをエスケープ処理してCSV形式に変換
URL⽣成: PMIDからPubMedのURLを⾃動⽣成

エスケープ処理の重要性

CSV形式では、フィールド内にカンマやダブルクォートが含まれる場合、適切にエスケープする必要があります。このコードでは、ダブルクォートを “” に変換することで、正しいCSV形式を保証しています。

出⼒

出⼒名	型	説明
csv_string	string	CSV形式の⽂字列

出⼒例

以下のように出⼒することで、SpreadsheetやExcelで扱いやすいcsvの形式にしています。これによってSpreadsheetやExcelに連携する時のデータ変換処理が容易になります。

"PMID","Priority","Title_JP","Summary","Title_EN","Authors","Journal","Year","DOI","MeSH_Keywords","URL","main_author_affiliation","research_area","publication_types","population""12345678","HIGH","糖尿病におけるインスリン療法の効果","本研究は、2型糖尿病患者におけるインスリン療法の有効性を検証した。...","Effect of Insulin Therapy in Type 2 Diabetes","John Smith, Jane Doe","Diabetes Research","2024","10.1234/example","diabetes, insulin, therapy","<https://pubmed.ncbi.nlm.nih.gov/12345678/","University> of Tokyo","内分泌","Randomized Controlled Trial","2型糖尿病患者（成人）"

4. まとめ

本記事では、取得した論⽂データに対してLLMで翻訳‧要約‧優先度判定を⾏い、CSV形式に整形する処理を詳しく解説しました。

本記事で実現したこと

イテレーションによる論⽂データのループ処理
LLMによる各論⽂の翻訳‧要約‧優先度判定
元データとAI分析結果のマージ
CSV形式への変換（エスケープ処理付き）

処理の流れの確認

イテレーション: 論⽂データをループ処理
LLM: 各論⽂に対して翻訳‧要約‧優先度判定‧研究領域抽出‧対象抽出
DB登録⽤データの作成: 元データとAI分析結果をマージしてCSV⽣成

次のステップ

次回のPart 4では、⽣成したCSVデータをGoogle Apps Script（GAS）へ送信してスプレッドシートに保存する処理と、GAS連携で実現できる応⽤例を解説します。具体的には以下のテーマを扱います。

CSV統合⽤の変数集約器
GAS WebhookへのPOST送信
レスポンスからスプレッドシートURLを取得するコード
Dify × GAS連携の応⽤（通知、定期実⾏、他システムとの統合等）

これらの処理により、ワークフローが完成し、ユーザーはスプレッドシートのURLを受け取って、保存された論⽂データを確認できるようになります。

シリーズ記事

Part0: 全体像とPubMed API基礎
Part 1: 検索・データ取得編
Part 2: AI処理・データ整形編
Part 3: LLM処理・データ保存編
Part4（次回記事）: DifyとGAS連携で実現する可能性

提供サービスの例

製薬・医療機器業界での提案活動や調査業務の自動化支援
アカデミアや研究者向けの文献レビュー・情報共有フローの最適化
医療従事者のキャリア開発を支援するリスキリングプログラム

👉 ご興味をお持ちの方はぜひお気軽にお問い合わせください。
お問い合わせフォームはこちら

監修者　株式会社ヘルツレーベン代表木下渉

2026年1月11日

Difyで作る論⽂仕分けアプリpart2: PubMedAPIから詳細を取得

AI_Dify, コラム一覧

1. はじめに
2. ワークフローの位置づけ
3. 各ノードの詳細解説
4. まとめ

1. はじめに

本記事は、Difyのチャットワークフローを使ってPubMed論⽂の検索‧翻訳‧要約を⾃動化するシリーズのPart 2です。

Part 1の振り返り:

⾃然⾔語クエリ（⽇本語）からPubMed検索パラメータを抽出
E-SearchでPMIDリストを取得
後段ノードに渡すためPMIDをカンマ区切り⽂字列へ整形

Part 2（本記事）では、PMIDリストをもとにE-Fetchで論⽂の詳細データを取得し、後続のAI処理で扱いやすい構造化データへ変換するまでを解説します。ここでは、PubMedから返却されるXMLのパース処理を丁寧に解説します。

シリーズ構成

Part0: 全体像とPubMed API基礎
Part 1: パラメータ抽出とE-Search編
Part 2（本記事）: E-Fetchとデータパース編
Part 3: AI処理‧データ整形編
Part4: データ保存とGAS連携編

2. ワークフローの位置づけ

Part 1で整形したPMID⽂字列は、これから紹介するノードに渡されます。

E-Fetch: 論⽂の詳細データを取得（XML形式）
XMLパース: LLM処理で扱いやすいPython dict / list形式へ変換

この簡易版では、E-Fetchのみを使⽤して論⽂の詳細データを取得します。E-Summaryは使⽤せず、常にE-FetchでXML形式のデータを取得することで、アブストラクトやMeSH⽤語などの詳細情報を確実に取得できます。

ここまでを整えることで、Part 3で実施するAI要約‧優先度付けをスムーズに実装できます。

3. 各ノードの詳細解説

3-1. E-Fetch（HTTP Requestノード）

PubMedの E-fetch APIを呼び出して、論⽂の詳細データをXML形式で取得するノードです。
この簡易版のワークフローでは、テスト⽤に retmax を固定で 3 に設定することで、最大取得件数を3件に抑えています。

パラメータ	値	説明
URL	https://eutils.ncbi.nlm.nih.gov/entrez/eutils/efetch.fcgi	PubMed E-Fetchエンドポイント
メソッド	GET

パラメータ

パラメータ	値	説明
db	pubmed	データベース名
id	{{#1764077943290.result#}}	カンマ区切りのPMID⽂字列（前のノードから取得）
retmode	xml	XMLレスポンスを取得
retmax	3	取得件数（テスト⽤に3件で固定）

特徴: Abstract、MeSH、著者、掲載誌など詳細なデータがすべて含まれるため、LLM要約やキーワード抽出に最適です。

3-2.XMLレスポンスのパース（Codeノード）

E-FetchのエンドポイントはXML形式のデータを返します。
通常のJSON文字列ではないため、コードブロックにてPythonのxml.etree.ElementTree を使って必要な項⽬を抽出・整形します。
（Difyでは標準的なPythonライブラリを呼び出して使うことができます）

以下のコードは理解していなくても⼤丈夫です。コピペで動かすことができます（コードブロックの⼊⼒変数と出⼒変数の名称や、タイプを揃えるよう注意してください）

主な抽出項⽬

項⽬	説明
pmid	PubMed ID
title	英語タイトル
abstract	AbstractTextに付与されたLabel込みで抽出し、改⾏で結合
author	著者⼀覧（”Forename Lastname”形式）
main_author_affiliation	第⼀著者の所属機関
journal_inshort	雑誌略称
journal	雑誌正式名称
year	公開年（ PubDate → DateCompleted の順に参照）
doi	DOI（ELocationIDから抽出）
MeSH_Keywords	著者キーワードとMeSH⽤語の統合（Qualifier含む場合はDescriptor/Qualifier 形式）
publication_types	論⽂タイプ（RCT、Review、Case Reportsなど）のリスト

コード詳細（コピペ⽤）

import xml.etree.ElementTree as ET
import json

def main(xml_string: str): 
  try:
    root = ET.fromstring(xml_string) 
  except ET.ParseError: 
    return {"parsed_result": []} 

  articles = []
  for article in root.findall('.//PubmedArticle'): 
    data = {} 

    # 1. pmid 
    pmid = article.find('.//PMID') 
    data['pmid'] = pmid.text if pmid is not None else "" 

    # 2. Title 
    title = article.find('.//ArticleTitle') 
    data['title'] = title.text if title is not None else "" 

    # 3.Abstract 
    abstract_texts = [] 
    abstract_section = article.find('.//Abstract') 

    if abstract_section is not None: 
      for text_node in abstract_section.findall('AbstractText'): 
        label = text_node.get('Label') 
        content = text_node.text or "" 
        if label: 
          abstract_texts.append(f"[{label}] {content}") 
        else: 
          abstract_texts.append(content) 
    data['abstract'] = "\n".join(abstract_texts)

    # 4. Authors & Affiliations 
    author_list = [] 
    for author in article.findall('.//Author'): 
      last = author.find('LastName') 
      fore = author.find('ForeName') 
      if last is not None and fore is not None: 
        author_list.append(f"{fore.text} {last.text}") 
      elif last is not None: 
        author_list.append(last.text) 
    data['author'] = author_list 

    main_author_affil = "" 
    first_author = article.find('.//AuthorList/Author') 
    if first_author is not None: 
      aff = first_author.find('.//AffiliationInfo/Affiliation') 
      if aff is not None and aff.text: 
        main_author_affil = aff.text.strip() 
    data['main_author_affiliation'] = main_author_affil 

    # 5-1.Journal(in short) info 
    journal_inshort = article.find('.//ISOAbbreviation') 
    data['journal_inshort'] = journal_inshort.text if journal_inshort is not None else "" 

    # 5-2. Journal_info 
    journal = article.find('.//Journal/Title') 
    data['journal'] = journal.text if journal is not None else "" 

    # 6.Year 
    year = article.find('.//PubDate/Year')
    if year is None: 
      year = article.find('.//DateCompleted/Year') 
    data['year'] = year.text if year is not None else "" 

    # 7.DOI 
    doi = "" 
    for eloc in article.findall('.//ELocationID'): 
      if eloc.get('EIdType') == 'doi': 
        doi = eloc.text 
        break 
    data['doi'] = doi 

    # 8.Keywords 
    keywords_set = set() 

    # A. 著者キーワード (KeywordList) 
    for kw in article.findall('.//Keyword'): 
      if kw.text: 
        keywords_set.add(kw.text.strip()) 

    # B. MeSH用語 (MeshHeadingList) 
    for mesh_heading in article.findall('.//MeshHeading'): 
      descriptor = mesh_heading.find('DescriptorName') 
      if descriptor is not None and descriptor.text: 
        desc_text = descriptor.text.strip() 

        # Qualifier 
        qualifiers = mesh_heading.findall('QualifierName') 

        if len(qualifiers) > 0: 
          for q in qualifiers: 
            if q.text: 
              keywords_set.add(f"{desc_text}/{q.text.strip()}") 
        else: 
          keywords_set.add(desc_text)

    # 9. Publication Types 
    pub_types = [] 
    for pt in article.findall('.//PublicationTypeList/PublicationType'): 
      if pt.text: 
        pub_types.append(pt.text.strip()) 
    data['publication_types'] = pub_types 

    # リストに戻してソート 
    data['MeSH_Keywords'] = sorted(list(keywords_set)) 
    articles.append(data) 

  return { 
    "parsed_result" : articles 
  }

出力

出⼒名	型	説明
parsed_result	array[object]	1レコード1論⽂の辞書リスト

4. まとめ

本記事で解説した内容

E-Fetchによる論⽂詳細データの取得（XML形式）
XMLレスポンスを構造化データへ変換するコード例
抽出される主要なフィールド（pmid、title、abstract、author、MeSH_Keywords、publication_typesなど）

次のステップ

Part 3では、ここで得た parsed_result を⼊⼒に、LLMでタイトル翻訳‧要約‧優先度判定を⾏います。イテレーションノードの並列処理やStructured Outputの活⽤法など、AI処理の中⼼部分を解説します。

シリーズ記事

Part0: 全体像とPubMed API基礎
Part 1: パラメータ抽出とE-Search編
Part 2: E-Fetchとデータパース編
Part 3（次回記事）: AI処理‧データ整形編
Part4: データ保存とGAS連携編

提供サービスの例

製薬・医療機器業界での提案活動や調査業務の自動化支援
アカデミアや研究者向けの文献レビュー・情報共有フローの最適化
医療従事者のキャリア開発を支援するリスキリングプログラム

👉 ご興味をお持ちの方はぜひお気軽にお問い合わせください。
お問い合わせフォームはこちら

監修者　株式会社ヘルツレーベン代表木下渉

2026年1月4日

Difyで作る論⽂仕分けアプリ Part1　　　　　　　　　　　　　　　　　　　　　　　質問から論⽂リストを取得

AI_Dify, コラム一覧

1. はじめに
2. ワークフローの全体像
3. 各ノードの詳細解説
4. まとめ

1. はじめに

本記事は、Difyのチャットワークフローを使って、PubMed論⽂の検索‧翻訳‧要約を⾃動化するシステムを構築するシリーズのPart 1です。

このシリーズでは、⾃然⾔語で検索クエリを⼊⼒して「論⽂検索→各論⽂のタイトルを⽇本語に翻訳→アブストラクト要約→Googleスプレッドシートに保存」という処理を一気に実現するワークフローについて解説します。

本記事（Part 1）では、ユーザー⼊⼒➔パラメータ抽出➔E-Search➔PMIDリスト整形までの処理を詳しく解説します。ここで整えたデータが後続のE-Fetch処理の⼟台になります。

このワークフローは、医学研究や⽂献調査の効率化に役⽴ち、特に⼤量の論⽂を扱う際の時間短縮に貢献します。

PubMed APIの基礎知識については、Part 0で詳しく解説していますので、本記事では各ノードの実装詳細に焦点を当てます。

シリーズ構成

Part0: 全体像とPubMed API基礎
Part 1（本記事）: パラメータ抽出とE-Search編
Part 2: E-Fetch とデータパース編
Part 3: AI処理‧データ整形編
Part4: データ保存とGAS連携編

2. ワークフローの全体像

このワークフローは、以下のような処理の流れで構成されています。

ユーザー⼊⼒: ⾃然⾔語での検索クエリ
現在年の取得: 年次フィルタリングに使⽤
パラメータ抽出: LLMが⾃然⾔語からPubMed検索パラメータを抽出
APIリクエスト整形: 抽出したパラメータをPubMed API形式に変換
E-Search: PubMedで論⽂ID（PMID）を検索
E-Fetch: 論⽂の詳細データ（XML）を取得
パース処理: XMLを構造化データに変換
イテレーション: 各論⽂に対してLLMで翻訳‧要約‧優先度判定
CSV⽣成: 論⽂データとAI分析結果をマージしてCSV形式に変換
GAS連携: Google Apps Scriptに送信してスプレッドシートに保存
結果返却: スプレッドシートのURLをユーザーに返却

本記事では、ステップ1〜5（E-SearchとPMID取得）までを詳しく解説します。E-Fetchとパース処理はPart 2で取り上げます。

3. 各ノードの詳細解説

3-1. ユーザー⼊⼒ノード（Start）

ワークフローの開始点となるノードです。ユーザーからの⾃然⾔語クエリを受け取ります。

設定内容

今回のワークフローでは、特に追加の設定不要です。

項⽬	設定値
ノードタイプ	Start
変数	なし

3-2.Current Time（Tool）

現在の年を取得するためのビルトインツールです。パラメータ抽出ノードで、ユーザーが「直近5年間の論⽂」のような相対的な期間指定をした際に、現在年を基準に min_year を計算するために使⽤されます。⽣成AIは基本的に「今、何⽇か？」といったデータを持っていません。そのため`CURRENT_TIME`のようなノードを使って、明⽰的に理解させる必要があります。

設定内容

項⽬	設定値
ツール名	Current Time
Format	%Y (年のみ)
Timezone	Asia/Tokyo

出⼒

text : 現在の年が出力されます（例: “2025”）

3-3.パラメータ抽出ノード（Parameter Extractor）

ユーザーの⾃然⾔語クエリ（主に⽇本語）から、PubMed APIで使⽤する検索パラメータを抽出するノードです。LLMを使⽤して構造化されたパラメータを⽣成します。このパラメータ抽出ノードがこの論⽂仕分けアプリにおいて最も重要なノードの⼀つです。

モデル設定

モデルはお好きなモデルをお使いください。

項⽬	設定値
モデル	gpt-4o-mini
プロバイダー	openai
Temperature	0.1

抽出パラメータ

パラメータ抽出ノードの [ + ]ボタンを押してパラメータを追加します。以下をそれぞれコピペして設定していくだけで⼤丈夫です。

パラメータ名	型	必須	説明（Description）
main_query	string	✅	The Search Term<br>Core topic, disease, drug, or therapy.<br><br>• Combine core concepts (e.g., “Relationship between A and B” → “A AND B”).<br>• Rule: Do NOT apply a [Title] tag here. Just provide the translated English term/MeSH.
title_filter	string	–	Strict Constraint<br>Drastically narrows results to highly relevant papers.<br><br>• Use ONLY when user explicitly says “Title must include…”, “Title search”, “タイトル検索”, or “タイトルに含まれる”.
author_filter	string	–	• Extract names<br>• Rule: Remove Japanese honorifics (e.g., “さん”, “⽒”, “先⽣”).
journal_filter	string	–	• Extract journals.
pub_type_filter	string	–	Identify implied study designs.<br><br>• “RCT”, “無作為化” → “Randomized Controlled Trial”<br>• “Review”, “まとめ” → “Review”<br>• “Meta- analysis” → “Meta-Analysis”<br>• “Case report”, “症例” → “Case Reports”
min_year	string	–	Start Date<br>The oldest year to include.<br><br>• “2023年以降”, “Since 2023″→”2023”
max_year	string	–	End Date<br>The newest year to include.
retmax	string	✅	Result Count<br>Number of papers to retrieve.<br> <br>• Extract explicit numbers: “10件”, “Top 5” → Integer (e.g., 10, 5).<br>• Default: 20 (if not specified).

プロンプト

LLMに与えるプロンプトは上記です。

※ 2ステップ⽬で作成した「CURRENT_NODE 」の出⼒を #current_yearの箇所に加えてあげることで、⽣成AIが「今、⻄暦何年か」を理解することができます。

## Role
You are an expert Medical Librarian and a PubMed Search API Specialist. Your goal is to extract search param eters from the user's natural language query (which is mostly in Japanese) and format them into a structured JSON object for the PubMed `esearch` API.

## Instructions
1.	**Translate to English**: The user input will be in Japanese. You must translate all search terms (Diseases, Drugs, Concepts) into **English** (specifically MeSH headings where applicable).
2.	**Extract Parameters**: Identify specific constraints based on the "Parameter Definition Table" below.
3.	**Determine Fetch Necessity**: Decide if the user needs `efetch` (detailed data like Abstract) or if `esumm ary` (metadata only) is sufficient.

## current_year
<year>{{/ ⟵ スラッシュボタンを押すとウィンドウが開くので、CURRENT_TIMEの出⼒を選択}}</year>
* use this year to extract `min_year` or `max_year`. if user needs 「直近5年間の〜」 it means that current_year
- 5 = min_year.

プロンプトには以下の重要な指⽰が含まれています。

翻訳ルール: ⽇本語の検索語を英語（特にMeSH⽤語）に翻訳
現在年の活⽤: Current Timeノードから現在年を取得し、「直近5年間」のような相対指定を絶対年へ変換
タイトルフィルタの厳格化: ユーザーが明⽰的に「タイトル検索」と⾔及した場合のみ title_filter を使⽤

3-4. API⽤リクエストデータ整形（Codeノード）

パラメータ抽出ノードで取得したパラメータを、PubMed APIの esearch エンドポイントで使⽤できる形式に整形するPythonコードノードです。

⼊⼒変数

変数名	ソース	型
main_query	パラメータ抽出ノード	string
title_filter	パラメータ抽出ノード	string
author_filter	パラメータ抽出ノード	string
author_filter	パラメータ抽出ノード	string
pub_type_filter	パラメータ抽出ノード	string
min_year	パラメータ抽出ノード	string
max_year	パラメータ抽出ノード	string
retmax	パラメータ抽出ノード	string

コードの処理内容

def main( 
  main_query: str, 
  title_filter: str, 
  author_filter: str, 
  journal_filter: str, 
  pub_type_filter: str, 
  min_year: str, 
  max_year: str, 
  retmax: str): 

# PubMedAPIへのクエリを格納する箱 
query_parts = [] 

# Main Query (主題) 
if main_query: 
  query_parts.append(f"({main_query})") 

# Title Filter (タイトル限定) 
if title_filter: 
  query_parts.append(f'"{title_filter}"[Title]') 

# Journal Filter (雑誌名) 
if journal_filter: 
  query_parts.append(f'"{journal_filter}"[Journal]') 

# Author Filter (著者名) 
if author_filter: 
  query_parts.append(f'"{author_filter}"[Author]') 

# Publication Type (研究デザイン) 
if pub_type_filter: 
  query_parts.append(f'"{pub_type_filter}"[Publication Type]') 

# 全てを AND で結合 
full_term = " AND ".join(query_parts) 

# フォールバック: 全て空の場合は全件検索 
if not full_term: 
  full_term = "all[sb]" 

# その他のパラメータ処理
final_retmax = retmax if retmax else "20" 
final_min_year = min_year if min_year else "" 
final_max_year = max_year if max_year else "" 

# 結果を返す 
return { 
  "search_term": full_term, 
  "retmax": final_retmax, 
  "mindate": final_min_year, 
  "maxdate": final_max_year, 
  "datetype": "pdat" 
}

処理の流れ

クエリパーツの構築: 各フィルタが存在する場合、PubMedの検索構⽂（ [Title] 、 [Journal] 、 [Author] 、 [Publication Type] ）を付与して配列に追加
AND結合:” AND “.join(query_parts)で全ての条件をANDで結合
デフォルト値処理:
- retmax が空の場合は”20″を設定
- ⽇付パラメータは空⽂字列のまま（API側で無視される）
フォールバック: 全てのクエリが空の場合は “all[sb]” （全件検索）を設定

出力

出⼒名	型	説明
search_term	string	PubMed検索クエリ（例: “(diabetes) AND \”insulin\”[Title]”）
retmax	string	取得件数
mindate	string	開始年
maxdate	string	終了年
datetype	string	⽇付タイプ（”pdat” = 公開⽇）

3-5. E-Search（HTTP Requestノード）

PubMedの E-search APIを呼び出して、検索条件に⼀致する論⽂のPMID（PubMed ID）リストを取得するノードです。

設定内容

上記の画像を参考にしながら、以下の項⽬を設定してください。

項⽬	設定値
メソッド	ヘッダー
URL	https://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi
認証	今回はなし（API_KEYによる認証を⾏うと⾼頻度‧⼤量にデータを取得可能）
ヘッダー	Content-Type:application/json

設定内容

パラメータ名	値	説明
db	pubmed	データベース（PubMed）
term	{{#search_term#}}	検索クエリ
retmax	{{#retmax#}}	取得件数
retmode	json	レスポンス形式
mindate	{{#mindate#}}	開始年
maxdate	{{#maxdate#}}	終了年

レスポンス例

{ 
  "esearchresult": { 
    "idlist": ["12345678", "23456789", "34567890"] 
  }
}

3-6. 配列を⽂字列に変換（Codeノード）

E-Searchのレスポンス（JSON形式）からPMIDの配列を抽出し、カンマ区切りの⽂字列に変換するノードです。次のE- Fetchノードで使⽤するため、PMIDを⽂字列形式に整形します。

⼊⼒変数

変数名	ソース	型
body	E-Searchノード	string

コード

import json

def main(body) -> dict:
# 値が空（想定外のエラー）の時はエラー 
if not body: 
  raise Exception("Invalid parameter") 

# pmidの配列を読み込み 
id_list = json.loads(body) 

# 配列をカンマ区切りで展開して返却 
return {
  "result": ",".join(id_list["esearchresult"]["idlist"]) 
}

処理の流れ

JSONパース: E-SearchのレスポンスをJSONとして解析
PMID抽出: esearchresult.idlist からPMIDの配列を取得
⽂字列変換: “,”.join() でカンマ区切りの⽂字列に変換（例: “12345678,23456789,34567890”）

出力

出⼒名	型	説明
result	string	string

4. まとめ

本記事（Part 1）では、DifyのチャットワークフローでPubMed検索を開始するための「前半戦」を解説しました。

本記事で実現したこと

⾃然⾔語クエリからPubMed検索パラメータへの変換
PubMed API（E-Search）での論⽂ID（PMID）検索
後続処理に渡すためのPMID⽂字列整形

次のステップ

次回のPart 2では、ここで取得したPMIDを⽤いてE-Fetchを呼び出し、論⽂の詳細データ（XML）を取得‧パースする処理を解説します。XMLから必要項⽬を抽出する実装を中⼼に取り上げます。

シリーズ記事

Part0: 全体像とPubMed API基礎
Part 1: パラメータ抽出とE-Search編
Part 2（次回記事）: E-Fetchとデータパース編
Part 3: AI処理‧データ整形編
Part4: データ保存とGAS連携編

提供サービスの例

製薬・医療機器業界での提案活動や調査業務の自動化支援
アカデミアや研究者向けの文献レビュー・情報共有フローの最適化
医療従事者のキャリア開発を支援するリスキリングプログラム

👉 ご興味をお持ちの方はぜひお気軽にお問い合わせください。
お問い合わせフォームはこちら

監修者　株式会社ヘルツレーベン代表木下渉

2025年12月28日

Difyで作る医学論⽂仕分けアプリ: 全体像とPubMedAPI基礎

AI_Dify, コラム一覧

1. はじめに
2. ワークフローの全体像
3. PubMed API基礎知識
4. このワークフローで実現すること
5. シリーズ構成
6. まとめ

1. はじめに

本シリーズでは、Difyのチャットワークフローを使⽤して、PubMed論⽂の検索‧翻訳‧要約を⾃動化するシステムの構築⽅法を解説します。

⾃然⾔語で検索クエリを⼊⼒すると、論⽂を検索し、各論⽂のタイトルを⽇本語に翻訳、アブストラクトを要約し、優先度を判定した上で、Googleスプレッドシートに保存するまでの⼀連の流れを実現します。

このワークフローは、医学研究や⽂献調査の効率化に役⽴ち、特に⼤量の論⽂を扱う際の時間短縮に貢献します。

1-1. 完成イメージ

完成イメージ（スプレッドシート） — スプレッドシートを⾒ると条件に⼀致する論⽂を保存してくれる（今回はテスト⽤に2件のみ）

本記事（Part 0）では、ワークフローの全体像とPubMed APIの基礎知識を解説します。これらを理解することで、以降のPart 1〜Part 4で解説する各ノードの実装がより深く理解できるようになります。

シリーズ構成

Part0（本記事）: 全体像とPubMed API基礎
Part 1: パラメータ抽出とE-Search編
Part 2: E-Fetchとデータパース編
Part 3: AI処理‧データ整形編
Part4: データ保存とGAS連携編

2. ワークフローの全体像

このワークフローは、以下の5つの主要なステップで構成されています。

2-1. ステップ1: 検索パラメータの抽出（Part 1）

ユーザーが⾃然⾔語で⼊⼒した検索クエリ（例: 「糖尿病のインスリン療法に関する2020年以降のRCT」）を、PubMed APIで使⽤できる検索パラメータに変換します。

⼊⼒: ⾃然⾔語クエリ（⽇本語）
処理: LLMによるパラメータ抽出
出⼒: 構造化された検索パラメータ（ main_query , title_filter , author_filter 等）

2-2. ステップ2: E-Fetchとデータパース（Part 2）

Part 1で⽣成したPMIDリストをもとに、⽤途に応じてE-Fetchまで論⽂詳細データを取得します。

論⽂詳細取得: E-Fetchによるデータ取得
E-Fetch: XMLレスポンスを取得
XML/JSONパース: LLMが扱いやすいPython dict/listへ整形

2-3. ステップ3: AIによる要約⽣成（Part 3）

取得した論⽂データに対して、LLMを使⽤して以下の処理を⾏います。

タイトル翻訳: 英語のタイトルを⾃然な⽇本語に翻訳
要約⽣成: アブストラクトを100〜200⽂字の⽇本語で要約
優先度判定: ユーザーの検索意図に基づいて、各論⽂の重要度をHIGH/MID/LOWで判定
データマージ: 元データとAI分析結果を統合
CSV⽣成: スプレッドシート保存⽤のCSV形式に変換

2-4. ステップ4: スプレッドシートへの保存（Part 4）

⽣成したCSVデータをGoogle Apps Script（GAS）経由でGoogleスプレッドシートに保存します。

GAS連携: CSVデータをGASのWebhookエンドポイントに送信
スプレッドシート保存: GASがCSVをパースしてスプレッドシートに追記
結果返却: スプレッドシートのURLをユーザーに返却

2-5.全体のデータフロー

ユーザー⼊⼒（⾃然⾔語）
↓
パラメータ抽出（LLM）
↓
E-Search（PMIDリスト取得）
↓
E-Fetch（詳細データ取得）
↓
XML/JSONパース
↓
イテレーション + LLM（翻訳‧要約‧優先度判定）
↓
CSV⽣成
↓
GAS連携（スプレッドシート保存）
↓
結果返却（URL）

3. PubMed API基礎知識

ワークフローの解説に映る前に、part0となる本記事では、PubMed APIについて解説します。

3-1. PubMed APIとは

PubMed APIは、⽶国国⽴医学図書館（NLM）が提供する⽣物医学分野の⽂献データベース「PubMed」にプログラムからアクセスするためのインターフェースです。正式名称は「Entrez Programming Utilities（E-utilities）」または「E-Utils」と呼ばれます。

このAPIを使⽤することで、プログラムからPubMedのデータを検索し、論⽂情報を⾃動的に取得‧処理することが可能になります。

3-2. 基本的な使⽤フロー

PubMed APIを使⽤する際は、以下の3つのステップを順番に実⾏する必要があります。

ステップ1: E-Search – 論⽂のリスト（PMID）を取得

まず、E-Searchを使⽤して、特定のキーワードや検索条件に合致する論⽂のPubMed ID（PMID）のリストを取得します。

重要なポイント: E-Searchは論⽂の詳細情報を返すのではなく、検索結果に該当する論⽂のPMID（識別番号）のリストのみを返します。このリストを取得することが、後続の処理の第⼀歩となります。

使用例:

https://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi?db=pubmed&term=cancer

このリクエストにより、キーワード「cancer」に該当する論⽂のPMIDリストを取得できます。

ステップ2: E-SummaryまたはE-Fetch – 詳細情報を取得

E-Searchで取得したPMIDリストを基に、E-SummaryまたはE-Fetchを使⽤して各論⽂の詳細情報を取得します。

3-3. E-SummaryとE-Fetchの使い分け

E-Summary: 軽量な概要情報の取得

取得できる情報:

タイトル
著者名
掲載誌名
出版年
基本的なメタデータ

特徴:

データ量が少なく、処理が⾼速
多数の論⽂の概要を⼀括で把握するのに適している
アブストラクト（要旨）は含まれない

使⽤例:

https://eutils.ncbi.nlm.nih.gov/entrez/eutils/esummary.fcgi?db=pubmed&id=12345678

E-Fetch: 詳細情報の取得

E-Fetchの⽅が詳細取得が可能なため、今回のワークフローではこちらをメインに使⽤します。

取得できる情報:

E-Summaryで取得できるすべての情報
アブストラクト（要旨）
MeSH⽤語（医学主題⾒出し）より詳細なメタデータ
全⽂へのリンク（利⽤可能な場合）

特徴:

アブストラクトや詳細な情報が必要な場合に使⽤
データが多いので必要最⼩限の論⽂に対して使⽤すると効率的

使⽤例:

<https://eutils.ncbi.nlm.nih.gov/entrez/eutils/efetch.fcgi?db=pubmed&id=12345678&retmode=xml>

使い分けの指針

まずE-Summaryで概要を確認: 多数の論⽂を処理する場合や、タイトルや著者などの基本情報だけで⼗分な場合は、E-Summaryを使⽤します。これにより、処理速度を向上させることができます。
必要に応じてE-Fetchで詳細を取得: アブストラクトやMeSH⽤語など、より詳細な情報が必要な場合のみ、E-Fetchを使⽤します。E- Fetchはデータ量が多いため、必要な論⽂に対してのみ使⽤することを推奨します。
効率的な処理フロー:
- E-SearchでPMIDリストを取得
- E-Summaryで全論⽂の概要を確認
- 必要な論⽂のみを選別
- 選別した論⽂に対してE-Fetchで詳細情報を取得

今回作成した論⽂仕分けアプリは、最終的にスプレッドシートに論⽂を蓄積していくことも⽬標の⼀つです。そのため、E-Summaryは使わずにE-Fetchを活⽤したフローとなっています。ただE-Summaryも使えるようなフローを作成したので興味がある⽅は、後続の記事を読んで試してみてください。

3-4. 注意点

レート制限

1秒間に3回以上のリクエストを⾏わないようにする必要があります
過度なリクエストを⾏うと、アクセスが制限される可能性があります
⼤量のデータを取得する場合は、適切な間隔を設けてリクエストを⾏います

APIキー

APIキーを取得することで、秒あたりのアクセス上限を増やすことが可能です
APIキーはNCBIのアカウントから取得できます

利⽤規約

NCBIの利⽤規約を遵守する必要があります
商⽤利⽤や⼤量のデータ取得を⾏う場合は、特に注意が必要です

3-5. PubMed APIのまとめ

PubMed APIを使⽤する際の基本的な流れは以下の通りです：

E-Search: 検索条件に基づいてPMIDリストを取得（必須の第⼀歩）
E-Summary: 基本的な情報を⾼速に取得（概要把握に適している）
E-Fetch: 詳細な情報を取得（アブストラクトなどが必要な場合のみ）

この3つのAPIを適切に組み合わせることで、効率的にPubMedから論⽂情報を取得し、研究や業務の効率化を図ることができます。

本ブログシリーズで解説するワークフローでは、E-Summaryは使⽤しませんが、E-Fetchと同様の⽅法で情報が取得できるため、興味のある⽅は試してみて下さい。

4. このワークフローで実現すること

このワークフローを構築することで、以下のようなことが実現できます。

4-1. ⾃然⾔語での論⽂検索

ユーザーは、複雑なPubMed検索構⽂を覚える必要がなく、⾃然⾔語で検索クエリを⼊⼒するだけで、適切な検索が実⾏されます。

例:

「糖尿病のインスリン療法に関する2020年以降のRCT」
「タイトルにCOVID-19を含むレビュー論⽂」
「⼭⽥太郎⽒が著者の2023年の論⽂」

4-2. ⾃動的な翻訳と要約

取得した論⽂のタイトルを⾃動的に⽇本語に翻訳し、アブストラクトを要約します。

これにより、英語が苦⼿な研究者でも、論⽂の内容を素早く把握できます。

4-3. 検索意図に基づく優先度判定

ユーザーの検索意図を考慮して、各論⽂の重要度を⾃動的に判定します。

これにより、⼤量の論⽂の中から、特に重要な論⽂を優先的に確認できます。

4-4. スプレッドシートへの⾃動保存

処理結果をGoogleスプレッドシートに⾃動保存することで、以下のメリットがあります。

共有が容易: チームメンバーと簡単に共有できる
分析が容易: スプレッドシートの機能を使って、データの分析や可視化が可能
履歴管理: 過去の検索結果を蓄積し、後から参照できる

5. シリーズ構成

本シリーズは、以下の5つの記事で構成されています。

パート	主な内容
Part 0（本記事）: 全体像とPubMed API基礎	・ワークフローの全体像・PubMed APIの基礎知識・このワークフローで実現すること
Part 1: パラメータ抽出とE-Search編	・ユーザー⼊⼒ノード・Current Time / パラメータ抽出ノード・E-SearchとPMID整形
Part 2: E-Fetch / E-Summaryとデータパース編	・E-Fetchによる論⽂情報取得・変数集約器とXML/JSONパース
Part 3: AI処理‧データ整形編	・イテレーション処理（並列）・LLMによる翻訳‧要約‧優先度判定・CSV⽣成処理
Part 4: データ保存とGAS連携編	・CSV統合とGASへのPOST送信・GASコードの詳細解説

6. まとめ

本記事（Part 0）では、Difyを使⽤した論⽂検索‧翻訳‧要約ワークフローの全体像と、PubMed APIの基礎知識を解説しました。

次のステップ

次回のPart 1では、⾃然⾔語クエリをPubMed検索パラメータへ落とし込み、E-SearchでPMIDリストを取得するところまでを詳しく解説します。具体的には、以下のノードを実装していきます。

開始ノード
Current Time取得（⽇付確認⽤）
⽂章からパラメーター取得（パラメータ抽出ノード）
API⽤リクエストデータ整形（Codeノード） E-Search（HTTP Requestノード）
PMID配列→⽂字列変換（Codeノード）

これらのノードを実装することで、⾃然⾔語での論⽂検索から詳細データの取得までが⾃動化されます。

シリーズ記事

Part0（本記事）: 全体像とPubMed API基礎
Part 1: パラメータ抽出とE-Search編
Part 2: E-Fetchとデータパース編
Part 3: AI処理‧データ整形編
Part4: データ保存とGAS連携編

提供サービスの例

製薬・医療機器業界での提案活動や調査業務の自動化支援
アカデミアや研究者向けの文献レビュー・情報共有フローの最適化
医療従事者のキャリア開発を支援するリスキリングプログラム

👉 ご興味をお持ちの方はぜひお気軽にお問い合わせください。
お問い合わせフォームはこちら

監修者　株式会社ヘルツレーベン代表木下渉

2025年12月23日

院内マニュアルAIをDifyで実現！RAGによる「当院ルール」遵守の仕組みを解説

AI_Dify, コラム一覧

医師や看護師、事務職にとって、膨大な院内マニュアルや手順書から必要な情報を瞬時に探し出す作業は、日常的なストレスであり、貴重な時間を奪う要因となっています。特に医療現場では、わずかな情報検索の遅れが患者の安全に関わる事態にも発展しかねません。このような課題を解決し、「当院のルール」に絶対的に準拠した回答を即座に提供できるAIアシスタントの導入が急務です。

本記事では、ノーコードAIプラットフォーム「Dify」を活用し、いかにして院内マニュアルを学習させた高精度なAIチャットボットを構築できるのか、その核心技術であるRAG（検索拡張生成）の仕組みと、医療機関特有のセキュリティを確保しながら導入する具体的な方法を、専門的な視点から徹底解説します。Difyを導入することで、開発時間を約80%短縮し、現場主導で業務特化型のAIミニアプリを量産することが可能になります。

RAG（検索拡張生成）の概念図。外部知識の検索、質問との結合、LLMによる生成の3ステップを示している。

1. 院内マニュアルAI導入の結論：Dify RAGがハルシネーションを防ぐ

院内マニュアルを覚えたAIを実現する上で、Difyが選ばれる決定的な理由は、その「高度なRAG（Retrieval-Augmented Generation：検索拡張生成）の簡単実装」にあります。大規模言語モデル（LLM）は、一般的な知識は豊富ですが、学習データにない病院独自のルールや最新の医療情報、ローカルな手順書には対応できません。また、事実に基づかないもっともらしい誤情報（ハルシネーション）を生成するリスクも存在します。

DifyのRAG機能は、この課題を解決します。ユーザーからの質問に対し、まずアップロードされた院内マニュアルのデータベースから最も関連性の高い情報を「検索（Retrieval）」し、その情報を根拠としてLLMに与え、正確な回答を「生成（Generation）」させます。これにより、AIは「一般的な正解」ではなく「当院のマニュアルに書かれた正解」のみを提示できるようになるのです。ある企業では、Difyの導入により、年間約18,000時間（1人当たり月1.5時間相当）の業務削減が実現したというデータもあり、AI開発のハードルを下げ、現場主導の業務効率化を加速させます。

💡 ポイント：Dify RAGが解決する課題

RAGは、LLMの「ハルシネーション（誤情報）」と「知識不足（院内ルール）」という二大弱点を克服します。Difyは、この複雑なRAGの一連の処理をノーコードで自動化し、開発期間を大幅に短縮します。特に、社内ナレッジを活かしたAIは、一般的なAIでは対応できない専門性の高い内容、例えば就業規則や特定の医療手順書に基づいた回答も可能にします。

【出典】

RAG（Retrieval-Augmented Generation）とは？最新情報と活用事例を解説 – BuzzAIMedia

(media.buzzconne.jp)

2. RAGの仕組み：マニュアルを「知識ベース」にする3つのステップ

Difyで院内マニュアルをAIに学習させるプロセスは、主に「知識ベースの作成」を通じて実現されます。この「知識ベース」こそが、RAGにおける外部データベースの役割を果たし、LLMが参照する独自の知識源となります。Difyでは、PDF、Word、Excelなど、さまざまな形式のドキュメントをこの知識ベースに簡単にインポートできます。

RAGシステムは、以下の3つのステップで動作し、院内マニュアルの知識を回答に反映させます。

検索（Retrieval）：ユーザーの質問（例：「深夜勤務時の休憩時間は？」）を分析し、それと意味的に関連性の高いマニュアルの箇所（チャンク）を知識ベースから抽出します。
拡張（Augmentation）：抽出されたマニュアルの具体的なテキスト情報が、元の質問文に「文脈（コンテキスト）」として追加されます。
生成（Generation）：拡張された質問文（質問＋マニュアルの根拠条文）がLLMに渡され、LLMは根拠に基づいた正確な文章として回答を生成します。

このプロセスにより、LLMは一般的な知識ではなく、アップロードされたマニュアルの情報を信頼できるソースとして利用し、ハルシネーションを最小限に抑えつつ、より正確で関連性の高い回答を提供できます。

【出典】

DifyでRAGを導入する方法と使い方！ナレッジ活用からチャットボット構築まで徹底解説 – trends

(trends.codecamp.jp)

3. 高精度な回答を可能にする「チャンキング」と「埋め込み」の技術

RAGの精度を左右する最も重要な要素の一つが、Difyが裏側で行っている「チャンキング（セグメント分割）」と「埋め込み（ベクトル化）」の処理です。院内マニュアルはしばしば数万字に及ぶ長文であり、そのままではAIが効率的に検索できません。そこでDifyは、ドキュメントを意味のまとまりごとに小さなブロック（チャンク）に分割します。

Difyは、RAGの精度を高めるために、単なる固定長分割だけでなく、「汎用分割」や、より高度な「親子分割（階層分割）」といったセグメント分類方法を提供しています。特に親子分割は、文書の構造や文脈を理解した単位（章や節）で分割できるため、検索の効率と精度が向上します。

さらに、Difyは分割された各チャンクを「埋め込みモデル」によって数値の羅列（ベクトル）に変換します。ユーザーの質問も同様にベクトル化され、知識ベース内のチャンクベクトルとの距離（類似度）を計算することで、最も関連性の高い情報ブロックを瞬時に特定します。これにより、マニュアルのどの部分が質問の意図と合致するかを正確に判断できるようになります。LLMを活用することで、文脈を理解したチャンク分割の自動化も可能になり、手作業による分割の工数を削減しつつ、RAGの品質を担保できます。

💡 ポイント：チャンキングの最適化

RAGの精度は「チャンク分割の品質」に大きく依存します。マニュアルの「章」や「節」といった意味単位で分割することで、AIは質問に対して、根拠となる文脈をまるごと取得でき、回答の信頼性を高めることが可能です。Difyのナレッジパイプライン機能は、この複雑な分割作業を効率化します。

【出典】

RAGの精度を向上させる方法は？チャンキングなど手法や落ちる原因、低精度で運用するリスクを徹底解説！

(ai-market.jp)

4. 【事例】院内マニュアルAIの具体的な活用シーンと導入手順

Difyで構築する院内マニュアルAIは、単なるFAQボットに留まらず、医療従事者の業務を多角的に支援できます。特に経験の浅い若手職員や新入職員の教育、医療の質の確保に大きく貢献します。例えば、心身障害児総合医療療育センターでは、看護手順書やヒヤリハット事例集をRAGシステムに学習させる実証実験（PoC）が行われ、看護指導部から高い評価を得ています。

具体的な活用シーンには、以下のものが挙げられます。

看護手順の即時検索：「特定疾患の点滴手順」や「人工呼吸器のアラーム対応」など、緊急性の高い情報を数秒で検索し、医療安全に貢献します。
ヒヤリハット事例の活用：「過去のインシデント事例」を検索し、同様の事態を防ぐための具体的な注意点や教訓を抽出します。
事務手続きの自動案内：「病棟間の物品移動申請手順」や「有給休暇の取得ルール」など、職員からの頻繁な問い合わせに自動で回答し、事務部門の負担を軽減します。

Difyでの導入は、プログラミング知識がなくても以下のステップで実現できます。

1ナレッジ（知識ベース）の作成

PDFやWord形式のマニュアルをDifyにアップロードし、知識ベースを作成します。この際、チャンキング設定を最適化します。

2RAG対応チャットボットアプリの作成

Difyのワークフロー機能（Chatflow）で「知識取得」ノードと「LLMノード」を接続し、作成したナレッジベースを紐づけます。

3動作確認とプロンプトチューニング

プレビュー画面で実際に質問を投げかけ、回答の精度を確認します。LLMへの指示（プロンプト）を調整し、回答のトーンや形式を「当院のルール」に合わせて最適化します。

【出典】

生成AIで業務/社内マニュアルを作成する方法【Dify活用編】 | NOVEL株式会社

(n-v-l.co)

5. 医療機関が最優先すべきDify導入のセキュリティと運用指針

機密性の高い医療情報を扱うAIシステムでは、機能性以上にセキュリティが最優先事項となります。Difyはオープンソースソフトウェアとして提供されており、クラウドサービスだけでなく、自社のサーバーにインストールして運用できる「セルフホスト版（オンプレミス）」に対応しています。これにより、機密情報や個人情報が外部のクラウドに流出するリスクを大幅に抑え、企業の厳格なセキュリティポリシーの下で生成AI技術を活用できます。

医療機関がDify RAGを導入する際は、厚生労働省が定める「医療情報システムの安全管理に関するガイドライン」への対応が必須です。具体的には、以下の点に留意する必要があります。

ローカル環境での運用：マニュアルやヒヤリハット事例などの機微情報を含むデータを外部に送信しないよう、オンプレミス環境でDifyを運用します。
入力データの再学習禁止：利用者がAIに入力した情報が、AIモデルの学習データとして再利用されない設定であることを確認し、プライバシーを保護します。
アクセスと権限の管理：利用ログの詳細な記録、職員の役割に応じたきめ細やかな権限管理を設定し、ITガバナンス要件に沿った運用を徹底します。

これらの対策を講じることで、AIによる業務効率化を図りつつ、情報漏洩のリスクを最小限に抑えた安全なシステム運用が可能となります。このガイドラインは、令和5年5月に第6.0版が公開されており、サイバーセキュリティ対策の優先的に取り組むべき事項がチェックリストにまとめられています。

⚠️ 注意：医療情報ガイドラインの遵守

医療機関でのAI導入においては、機能検証よりもまずセキュリティ対策が優先されます。特に「医療情報システムの安全管理に関するガイドライン」に基づき、ローカル環境での運用、入力データの匿名化・再学習禁止設定、厳格なアクセス権限管理を徹底することが、法令遵守と患者からの信頼確保に不可欠です。

まとめ

Difyを活用した「院内マニュアルAI」は、医療現場のナレッジ活用と業務効率化を一気に加速させるソリューションです。その核心は、院内マニュアルを外部知識源とするRAG（検索拡張生成）の仕組みにあり、これによりAIは一般的な回答ではなく、「当院のルール」という独自の文脈に基づいた、根拠のある正確な回答を生成できます。Difyのノーコード開発環境は、プログラミング知識がない現場担当者でも、PDFやWord形式のマニュアルをアップロードし、数ステップでRAGチャットボットを構築することを可能にします。

医療機関特有のセキュリティ課題に対しては、Difyのセルフホスト（オンプレミス）運用を選択することで、機密データを外部に漏らすことなく、厚生労働省のガイドラインに準拠した安全な環境でのAI活用を実現できます。情報検索にかかる時間を削減し、職員の教育と医療の質向上に貢献するDify RAGの導入は、医療DXを推進する上での強力な一手となるでしょう。

監修者

株式会社ヘルツレーベン代表木下渉

株式会社ヘルツレーベン代表取締役／医療・製薬・医療機器領域に特化したDXコンサルタント／
横浜市立大学大学院ヘルスデータサイエンス研究科修了。
製薬・医療機器企業向けのデータ利活用支援、提案代行、営業戦略支援を中心に、医療従事者向けのデジタルスキル教育にも取り組む。AI・データ活用の専門家として、企業研修、プロジェクトPMO、生成AI導入支援など幅広く活動中。

https://herzleben.co.jp/

2025年12月22日

ChatGPTとDify、医療現場のAI使い分け戦略と劇的なコスト削減術

AI_Dify, コラム一覧

現代の医療現場は、医師や看護師の記録業務過重、人手不足、そして複雑化する診療ガイドラインへの迅速な対応という三重苦に直面しています。これらの課題を解決する鍵として、生成AIの導入が急速に進んでいますが、単に「ChatGPTを使えば良い」という単純な話ではありません。汎用的なAIと、専門的なタスクに特化したAI開発プラットフォームを戦略的に使い分けることが、業務効率化とコスト削減を劇的に進める最重要戦略となります。

本記事では、汎用AIの代表格であるChatGPTと、ノーコードでRAG（検索拡張生成）システムを構築できるDifyに焦点を当て、医療機関が両者をどのように使い分け、年間数億円規模のコスト削減を達成できるのかを、具体的なデータと事例に基づいてプロフェッショナルな視点から徹底解説します。AI導入による業務変革と、医療情報特有のセキュリティ・倫理的課題への対応策も網羅しています。

医療現場で働く医師と看護師。彼らの周りには汎用AIと特化型AIプラットフォームの使い分けを示すホログラフィックなAIインターフェースが表示されている。

1. 結論：医療現場におけるAI使い分けの最適解

医療現場におけるChatGPTとDifyの最適な使い分けは、「汎用的な情報生成・対話」と「専門的なナレッジベース連携・業務自動化」の二極化戦略にあります。ChatGPTは、その優れた自然言語処理能力を活かし、一般的な文書作成や教育、アイデア出しなど、アウトプットの質と速度が求められる汎用業務（フロントオフィス業務の一部）に適しています。一方、Difyは、RAG（検索拡張生成）やワークフロー構築といった機能により、院内の電子カルテや最新の診療ガイドラインなどの独自データに基づいた高精度な回答と、複雑な業務の自動化（バックオフィス業務）にその真価を発揮します。この戦略的使い分けにより、AIの利用コストを最適化しつつ、業務効率を最大化することが可能です。

例えば、DifyはLLMオーケストレーションやビジュアルワークフロービルダーを提供しており、誰でも短時間で本格的な生成AIアプリを構築できる「AIアプリ開発のキッチン」のような存在です。これに対し、ChatGPTはそのまま使える「完成品の料理」であり、特定のデータベース連携は基本的にできません。医療機関は、この機能的な違いを理解し、機密情報を扱わない汎用的なタスクにはChatGPTを、機密性の高い専門的なタスクにはDifyをオンプレミス環境で利用するなど、目的とセキュリティレベルに応じてAIを使い分けるべきです。

比較項目	ChatGPT（汎用AI）	Dify（特化型AIプラットフォーム）
カテゴリ	対話型AI（完成品）	AIアプリ開発プラットフォーム（ノーコード）
得意な業務	一般的な文書作成、教育、アイデア出し、広報文ドラフト	RAGによる専門知識検索、業務自動化ワークフロー、院内FAQ
独自データ連携（RAG）	基本的に不可（プラグインなどで限定的）	核心機能として実装（社内文書、カルテ、ガイドライン）
セキュリティ/導入形態	クラウド利用が基本	クラウド・オンプレミス（自社サーバー）の両方に対応

✅ 使い分けのメリット

コスト効率の最大化: 汎用業務には安価なChatGPT、専門業務にはDifyを限定的に適用。
回答精度の向上: 機密性の高い業務でRAG（Dify）を使うことでハルシネーション（誤情報生成）リスクを低減。

❌ 使い分けのデメリット

導入の複雑性: 2つのツールを運用するための初期設定や連携の手間が発生する。
学習コスト: 現場スタッフが各ツールの特性と利用ルールを理解する必要がある。

【出典】

「AIツールは使えない」が常識だった企業が、なぜDifyに殺到しているのか？ – GPT Master

(chatgpt-enterprise.jp)

2. 汎用AI：ChatGPTの強みと「フロントオフィス」活用シーン

ChatGPTは、その膨大な学習データに基づいた高い汎用性と、直感的な操作性により、医療現場の非診療業務における「ファーストドラフト作成」や「情報整理」において圧倒的な効率を発揮します。特に、機密性の低い、または匿名化が容易な業務に最適です。

具体的な活用シーンとしては、以下の業務が挙げられます。これにより、医師や看護師の年間業務時間を約20%以上削減できる可能性があります。例えば、退院時サマリーの作成業務は、生成AIの活用により、作成時間を最大1/3に短縮できた成功事例が報告されています。

紹介状・サマリーのドラフト作成: 診療記録やメモをインプットし、定型フォーマットに沿った紹介状や退院時サマリーの雛形を瞬時に作成します。
患者向け説明資料の作成支援: 専門的な病状や治療法を、一般患者向けに分かりやすい言葉に変換・要約するタスクを支援します。
論文・研究情報の要約とレビュー: 膨大な医学論文から要点を抽出し、研究テーマに関連する情報を収集・整理する時間を大幅に短縮します。
スタッフ教育マニュアルの生成: 既存の業務手順書を元に、新人向けの研修資料やクイズ、シフト表の自動ドラフトを生成します。

ChatGPTは、これらの「人件費がかかっていたが、必ずしも専門知識を必要としない文書業務」を代替することで、医療スタッフを本来の診療・ケア業務に集中させることを可能にします。

💡 ポイント：プロンプトエンジニアリング

ChatGPTを医療現場で活用する際は、「あなたは経験豊富な専門医です。この患者のカルテ（匿名化済み）を基に、退院サマリーの構成案をMarkdown形式で作成してください。」のように、AIに明確な役割（ペルソナ）と出力形式を指定するプロンプトエンジニアリングが重要です。これにより、回答の精度と実用性を約30%向上させることができます。

【出典】

2025年版三大AIアシスタント徹底比較！ChatGPT・Claude・Geminiの強みと使い分け術

(www.room8.co.jp)

3. 特化型プラットフォーム：DifyのRAGと「バックオフィス」自動化

Difyの最大の強みは、RAG（Retrieval-Augmented Generation：検索拡張生成）技術をノーコードで実装できる点にあります。医療現場特有の課題である「機密性の高い院内情報」や「常に更新される専門知識」をAIに学習させ、その情報に基づいた正確な回答を生成させることが可能です。これにより、ハルシネーション（AIの誤情報生成）のリスクを大幅に低減できます。

Difyを導入することで、医療従事者や事務担当者でも、自分たちの業務に特化したAIツールを構築・運用できるようになります。実際、那須赤十字病院では、Difyをオンプレミス環境に導入し、電子カルテと連携させることで、医師の負担となっていた退院サマリー作成業務の効率化を実現していますこれは、Difyのセキュアな導入形態とRAG機能が、機密性の高い医療データ活用に極めて適していることを示しています。

専門ナレッジベースの構築: 最新の臨床ガイドライン、院内規定、過去の症例報告などをDifyにアップロードし、専門知識に特化したAIチャットボットを構築します。
医療事務ワークフローの自動化: 予約管理、頻出質問への自動応答、特定の診断コードに基づく次のステップ（例：検査予約の自動提案）といった複雑な業務フローをノーコードで自動化します。
臨床支援AIエージェントの開発: 患者記録を要約し、医師の意思決定を支援するAIエージェントを、Difyのビジュアルオーケストレーション機能を使って開発します。

💡 ポイント：RAGによる精度向上

RAG技術は、LLMが持つ一般的な知識と、アップロードされた「独自のナレッジ（医療文書）」を組み合わせて回答を生成します。これにより、回答の信頼性が約40%向上するという試算もあり、最新の医療情報を参照する専門業務において、DifyのRAG機能は必須の技術となっています。

【出典】

Dify導入事例10選｜業務効率化・社内活用の成功パターンと注意点を解説 – Sun* / サンアスタリスク

(sun-asterisk.com)

4. コスト劇的削減のメカニズム：AI連携がもたらす経営インパクト

AIの戦略的な使い分けがコスト削減に直結するメカニズムは、「人件費の最適化」「業務効率化による医療資源の最適配分」「診断精度向上による無駄な医療行為の削減」の3点に集約されます。ChatGPTで汎用的な文書作成時間を削減し、DifyでRAGを活用した専門業務を自動化することで、医療スタッフは高付加価値な診療・患者ケアに集中できます。これにより、間接的な事務作業に費やされていた人件費が、本来の医療サービスへと振り向けられます。

海外の成功事例では、米フロリダ州のタンパ総合病院がGEヘルスケアのAIテクノロジー群を導入した結果、医療システムの非効率を避けることで、実に4,000万ドル（約52億円）ものコスト削減に成功しています。また、AIによるワークフローの効率化は、平均入院日数を6日から5.5日に短縮させ、ICUへの入院を25%減少させました。これは、AIが診断支援や最適な予約スケジュール作成を担うことで、医療資源の最適配分が進み、無駄な入院や再診が減った結果です。AI導入は、単なるツールの置き換えではなく、病院経営の抜本的な改革となり得るのです。

コスト削減要因	AI活用の具体例	期待される効果（データ例）
人件費の最適化	カルテ作成、サマリー作成の自動化（ChatGPT/Dify）	ドキュメント作成時間を最大67%短縮
医療資源の最適配分	AIによる予約管理、病床管理（Difyワークフロー）	平均入院日数を6日から5.5日に短縮
診断精度向上	画像診断支援AI、鑑別診断リスト作成（Dify RAG連携）	高血圧を約90%の精度で判定するAIシステム

AIは、医師の意思決定を支援し、適切な治療方針を速やかに立てることを可能にするため、結果的に治療期間や入院日数の短縮に寄与し、長期的な医療費の低減に貢献します。

【出典】

医療業界で進むAI活用｜Difyで実現する現場支援と業務効率化 – ノーコード総合研究所

(nocoderi.co.jp)

5. 医療の信頼性を守る：セキュリティとガイドライン遵守の鉄則

ChatGPTとDifyの使い分けにおいて、最も重要な要素がセキュリティと倫理的配慮です。医療現場で扱うデータは「要配慮個人情報」に該当するため、AI利用にあたっては、厚生労働省が定めるガイドラインを厳格に遵守しなければなりません。特に、ChatGPTのような汎用クラウドサービスを利用する際は、機密情報や個人情報を絶対に入力しないというルールを徹底することが不可欠です。

この点で、Difyがセキュアなオンプレミス（自社サーバー）環境への展開を可能にしている点は大きな優位性となります。院内に閉じたネットワークでRAGシステムを運用すれば、外部への情報漏洩リスクを最小限に抑えつつ、電子カルテデータなどの機密性の高い情報をAI活用に役立てることが可能です。医療機関は、以下のステップでAI導入のリスク管理を徹底する必要があります。

1利用ルールの策定と周知

機密情報を扱わない業務（広報文作成など）に限定してChatGPTの利用を許可するなど、利用目的と範囲を明確にした院内ガイドラインを策定します。

2データ匿名化の徹底

AIに入力するデータは、個人情報保護法や「医療情報システムの安全管理に関するガイドライン」に基づき、氏名、生年月日、病名などの機密情報を完全に匿名化・仮名加工するプロセスを必須とします。

3専門AIのセキュアな運用

Difyなどのプラットフォームを活用し、RAG用ナレッジベースを院内ネットワークまたはセキュアなプライベートクラウドで運用する「セルフホスト」構成を選択します。

⚠️ 注意：ハルシネーションと最終責任

生成AIが作成した文書や診断支援情報は、必ず最終的な医療従事者が内容を確認し、責任をもって判断を下す必要があります。AIの誤情報生成（ハルシネーション）はゼロにはならないため、AIの回答をそのまま患者に提供したり、診療に利用したりすることは絶対に避けてください。

【出典】

(nicoms.nicho.co.jp)

まとめ

医療現場におけるAI導入の成功は、ChatGPT（汎用AI）とDify（特化型AIプラットフォーム）の戦略的な使い分けにかかっています。ChatGPTは、情報収集や文書のファーストドラフト作成といった汎用的な「フロントオフィス」業務を効率化し、医師の事務負担を軽減します。一方、DifyはRAG機能を活用し、院内データや臨床ガイドラインに基づいた高精度な回答と、複雑な業務の自動化ワークフローを提供することで、機密性の高い「バックオフィス」業務の質と速度を向上させます。この使い分けにより、タンパ総合病院の事例のように、年間数億円規模のコスト削減効果が現実のものとなります。導入にあたっては、厚生労働省のガイドラインを遵守し、Difyのオンプレミス運用などを通じてセキュリティとデータ匿名化を徹底することが、医療の信頼性を維持するための鉄則となります。AIを単なるツールではなく、経営戦略の一環として捉え、高効率・高精度・高セキュリティな医療体制の実現を目指しましょう。

【出典】

52兆円のコストを削減、「AIで医療を効率化」する世界のスタートアップ最前線

(forbesjapan.com)

監修者

株式会社ヘルツレーベン代表木下渉

https://herzleben.co.jp/

2025年12月21日

Difyは日本語で使える？インストールからRAG構築までの基本ガイド

AI_Dify, コラム一覧

Dify（ディフィー）は、プログラミングスキルがなくても高品質なAIアプリケーションを開発できる、オープンソースのプラットフォームです。RAG（検索拡張生成）機能の組み込みが容易なことから、特に社内ナレッジを活用したチャットボット開発ツールとして注目を集めています。本記事では、「Difyは日本語で利用できるのか」という疑問から、セルフホストでのインストール方法、そしてDifyの最大の特長であるRAGアプリケーションの基本的な構築手順までを、メディカル・テクニカルライターの視点から徹底的に解説します。

Dify（ディフィー）とは？その特徴と主要機能

Difyは、ノーコード（No-code）やローコード（Low-code）でAIアプリケーションを開発できるオープンソースのプラットフォームです。大規模言語モデル（LLM）の活用を容易にし、専門知識がなくても独自のAIサービスを迅速に構築できる点が最大の魅力です。

ノーコード・ローコード開発: プログラミングの知識が少なくても、直感的なインターフェース（UI）操作だけで、チャットボットやコンテンツ生成システムなどのAIアプリを作成できます。
RAG（検索拡張生成）エンジンの標準搭載: 外部のナレッジベース（業務マニュアル、PDF、Webサイトなど）を参照し、より正確で最新の情報に基づいた回答を生成するRAG機能が標準で組み込まれています。これにより、AIの「ハルシネーション（幻覚）」の削減と、ドメイン特化の知識活用が可能になります。
多様なLLMへの対応: OpenAIのGPTシリーズ、AnthropicのClaude、さらにはローカルモデルなど、多様なLLMと柔軟に接続・切り替えが可能です。
オープンソース: Apache License 2.0で公開されており、クラウド版（SaaS）と自社サーバーにデプロイするセルフホスティング版の選択が可能です。企業のセキュリティ要件に応じて利用環境を選べる柔軟性を持っています。

Difyの日本語対応状況と利用上のメリット

ユーザーが最も気になる「Difyは日本語で使えるか」という点について、結論から言うと、Difyは日本語に完全に対応しています。

まず、作成するAIアプリケーション自体は、LLMが日本語に対応していれば、高い精度で日本語の入出力に対応可能です。これにより、敬語や文脈を理解した自然な日本語での対話やコンテンツ生成を実現できます。

さらに、Difyの管理画面（UI）についても、日本語対応が進んでおり、日本語での操作が可能です。これにより、英語のドキュメントやインターフェースに不慣れな日本のビジネスユーザーや非エンジニアでも、安心してAIアプリケーションの開発・運用を進めることができるのが大きなメリットです。

また、日本国内では大手IT企業がDifyの正規代理店として販売・サポートを行っている事例もあり、日本語での導入サポート体制も整ってきています。

セルフホスト環境の構築：Dockerを使ったインストール手順（概要）

Difyを自社のセキュリティ環境下で利用したい場合や、クラウド版の制限を受けたくない場合は、セルフホスティング版（ローカル環境や自社サーバーへのデプロイ）が選択肢となります。Difyのセルフホストは、DockerおよびDocker Composeを利用した方法が最も一般的で推奨されています。

基本的なインストール手順は以下の通りです。

事前準備: Git、およびDocker Desktop（Docker EngineとDocker Composeを含む）を、利用するOS（Windows/Mac/Linux）に合わせてインストールします。Difyの推奨動作環境として、CPU 2コア以上、RAM 4GB以上などが目安とされます。
ソースコードのクローン: DifyのGitHubリポジトリからソースコードをローカル環境にクローンします。
設定ファイルの準備: クローンしたディレクトリ内のDocker関連フォルダに移動し、環境変数のサンプルファイル（.env.example）をコピーして、実際に利用する環境ファイル（.env）を作成します。
Docker Composeの起動: ターミナルでdocker compose up -dコマンドを実行し、Difyに必要なAPI、Web、DB（PostgreSQL）、Redis、Weaviate（ベクトルDB）などの全コンテナを一括で起動します。
初期設定: 起動後、ブラウザから指定されたローカルホストのURL（例: http://localhost/install）にアクセスし、管理者アカウントの設定と初期ログインを行います。

この方法により、Difyに必要な複数のコンポーネントがコンテナ技術によって一括管理され、スムーズな導入が可能となります。

【参照】

【Dify入門】初心者向けローカル環境構築の方法！Dockerで簡単セットアップ

(miralab.co.jp)

Difyの基本的な使い方：RAGアプリケーションを構築する流れ

Difyの利用目的の多くは、独自の知識に基づいたRAGチャットボットの構築です。ここでは、データを取り込み、チャットボットとして公開するまでの基本的な手順を紹介します。

新規アプリケーションの作成: ログイン後、「スタジオ」画面から「最初から作成」を選択し、アプリケーションタイプとして「チャットボット」または「テキスト生成器」を選びます。
ナレッジベースの作成: アプリケーションとは別に、RAG機能で参照させたい情報源（ナレッジ）を登録します。画面上部の「ナレッジ」タブから「ナレッジの作成」へ進みます。
ドキュメントのアップロードとインデックス化: 参照させたいPDFファイル、テキストファイル、Webページなどをアップロードします。アップロード後、Difyはデータを細かく区切る「チャンク分割」と、それをベクトルデータに変換する「インデックス化」を自動で行います。この際、チャンクサイズや重複率などの設定を調整することで、RAGの精度を向上させることが可能です。
アプリケーションへのナレッジの組み込み: 作成したチャットボットの編集画面に戻り、「コンテキスト（ナレッジ）」設定で、作成済みのナレッジベースを有効化します。これにより、ユーザーからの質問に対し、登録したナレッジベースを参照して回答する仕組みが完成します。
公開と利用: プロンプトやモデル設定を調整した後、作成したアプリケーションを公開します。公開されたアプリはWebリンクやAPI経由で利用可能となり、社内での問い合わせ対応や情報検索などに活用できます。

このようにDifyは、高度なRAGシステム構築を、ノーコードの直感的なUIで実現できるため、AI開発のハードルを大きく下げています。

まとめ

Dify（ディフィー）は、ノーコード・ローコードでAIアプリを開発できるオープンソースプラットフォームであり、日本語に完全対応しています。UIの一部で英語表示が残る可能性はあるものの、管理画面、そして作成されるAIアプリ自体は高い精度で日本語に対応可能です。セルフホスティングを行う場合は、Docker Composeを使った方法が最も一般的で、比較的容易に環境構築ができます。Difyの最大の強みは、業務マニュアルなどの独自データを活用するRAG（検索拡張生成）機能を、非エンジニアでも直感的な操作で組み込める点にあり、社内のDX推進を強力にサポートするツールとして期待されています。

監修者

株式会社ヘルツレーベン代表木下渉

https://herzleben.co.jp/

株式会社ヘルツレーベン
お問い合わせ

CONTENT

私たちについて　サービス内容　 DX人材育成　導入事例　会社概要　お役立ち情報　お知らせ　資料請求

AI_Dify

Difyで構築した医療AIの「暴走」を防ぐ！安全設計を実現する3つの運用ポイント

1. 医療AIの暴走を防ぐ3つの運用ポイント

2. 運用ポイント1: 厳格なRAG設計と信頼できる知識ベースの構築

【出典】

3. 運用ポイント2: AIガードレールとプロンプトエンジニアリングの徹底

4. 運用ポイント3: LLMOpsとHuman-in-the-Loopによる継続的改善

5. 補足情報・注意点：医療分野特有のコンプライアンスとセキュリティ対策

まとめ

【出典】

株式会社ヘルツレーベン代表 木下 渉

Difyエージェントの安全設計ロードマップ：医療AIの信頼性を高める出力制御

1. 医療AIにおける「ハルシネーション」の深刻なリスク

【出典】

2. 結論：信頼されるAI運用のための多層的出力制御ロードマップ

3. ステップ1: プロンプトエンジニアリングによる初期安全性の確保

【出典】

4. ステップ2: RAGとTool Callingによる情報源とアクションの限定

5. ステップ3: 後処理（Post-processing）による最終出力の検証とフィルタリング

6. 医療AIの法的・倫理的課題と「Human-in-the-Loop」原則

まとめ

【出典】

株式会社ヘルツレーベン代表 木下 渉

1. はじめに

2. Part 3からの流れ

3. Dify側の保存フロー

3-1. GASに追記（HTTP Request）

3-2.スプレッドシートURLを抽出

3-3. Answerノード

4. Google Apps Scriptとは？

4-1. Google Apps Scriptの概要

4-2. Google Apps Scriptの主な特徴

5. GASの作り⽅とデプロイ⼿順

5-1. Google Apps Scriptエディタの開き⽅

5-2. コードの記述

5-3. Webアプリとしてデプロイする⽅法

ステップ1: デプロイメニューを開く

ステップ2: デプロイ設定

ステップ3: デプロイ実⾏

ステップ4: WebアプリのURLを取得

5-4. DifyでURLを設定

5-5. デプロイ時の注意点

6. 動作確認とプレビュー

6-1. ワークフロー全体の動作確認

7. まとめ

本記事で実現したこと

Dify×GAS連携のポイント

次のステップ

1. はじめに

2. ワークフローの位置付け

3. 各ノードの詳細解説

3-1. イテレーション（Iteration）

3-2.LLM（イテレーション内側のノードです）

3-3. DB登録⽤データの作成（Codeノード）

4. まとめ

本記事で実現したこと

処理の流れの確認

次のステップ

1. はじめに

2. ワークフローの位置づけ

3. 各ノードの詳細解説

3-1. E-Fetch（HTTP Requestノード）

3-2.XMLレスポンスのパース（Codeノード）

4. まとめ

本記事で解説した内容

次のステップ

1. はじめに

2. ワークフローの全体像

3. 各ノードの詳細解説

3-1. ユーザー⼊⼒ノード（Start）

3-2.Current Time（Tool）

3-3.パラメータ抽出ノード（Parameter Extractor）

3-4. API⽤リクエストデータ整形（Codeノード）

3-5. E-Search（HTTP Requestノード）

3-6. 配列を⽂字列に変換（Codeノード）

4. まとめ

本記事で実現したこと

次のステップ

1. はじめに

1-1. 完成イメージ

株式会社ヘルツレーベン代表木下渉

株式会社ヘルツレーベン代表木下渉

株式会社ヘルツレーベン代表木下渉

株式会社ヘルツレーベン代表木下渉