---
title: "Difyでチャットボットを作る手順｜種別の選び分けと社内ナレッジ設定【2026年版】"
url: "https://www.issoh.co.jp/tech/details/2758/"
published: 2024-06-25
updated: 2026-09-16
categories: ["Dify"]
publisher: "株式会社一創"
---

# Difyでチャットボットを作る手順｜種別の選び分けと社内ナレッジ設定【2026年版】

Difyでチャットボットを作る作業自体は、アプリを作ってプロンプトを書き、ナレッジをつなぐだけで終わります。つまずくのはその先です。少し会話が続くと前半の指示を忘れる、社内文書を入れた途端に無料枠が埋まる、APIから叩いたら400が返る。いずれもDifyの仕様に上限や制約が明記されているのに、日本語の手順記事がスクリーンショットの羅列で終わっているために踏む落とし穴です。この記事では、アプリ種別の選び分けから社内公開・API連携までを、公式ドキュメントに書かれた実際の数値と挙動に沿って追います。検証はDify 1.16.1（2026年7月28日リリース）時点のものです。

## まとめ：Difyのチャットボット構築で先に決める4点

手を動かす前に決めておくと後戻りしないのは次の4点です。第一に**アプリ種別**。プロンプトとナレッジだけで足りるならChatbot、質問の種類で応答を分けたいならChatflowです。ChatbotはあとからChatflowへ変換できますが、Agentは変換対象外なので選び直しが効きません。第二に**索引方法**。High Qualityを選ぶとベクトルがワークスペースの容量を食い、無料のSandboxは50MBしかありません。第三に**公開形態**。リンク共有・iframe・チャットバブル・APIで必要な作業量が変わります。第四に**会話履歴の上限**で、ChatbotとAgentは1会話あたり500メッセージまたは2,000トークンを超えた分から古い順に捨てられます。長い問い合わせ対応を想定するなら設計段階で織り込む必要があります。

## 会話型アプリ4種類の選び分けと、変換が効く範囲

Difyのアプリは Chatflow / Workflow / New Agent / Chatbot / Agent / Text Generator の6種類です。このうち会話形式で動くのは Chatbot・Agent・New Agent・Chatflow の4つで、「チャットボットを作る」と言ったときの選択肢はここに絞られます。Workflow と Text Generator は一問一答で完結する処理なので、対話履歴を持ちません。

### Chatbot：モデルとプロンプトだけで完結する最小構成

公式ドキュメントはChatbotを「The simplest way to build a conversational app with a model and a prompt」と定義し、想定用途として「building an internal Q&A assistant grounded in your team’s knowledge base」を挙げています。社内ナレッジに答えさせる用途は、まさにこのChatbotの標準ケースです。ツール呼び出しも多段処理も不要なら、フロー図を組む必要はありません。

プロンプトには変数を置けます。`{{role}}` のようなプレースホルダを埋め込むと、会話開始前の入力欄になり実行時に値が差し込まれます。変数の型は Short Text（256文字まで）・Paragraph（長さ制限なし）・Select（ドロップダウン）・Number・Checkbox（true/false）・API-based Variable（外部APIから実行時に取得）の6種類です。値は会話の途中でも更新でき、変更はその時点からプロンプトに反映されます。部署ごとに口調や参照範囲を変えたいなら、Selectで部署を選ばせるのが最短です。

### Chatflow：質問の種類で応答を分ける場合

問い合わせ内容によって処理を変えたいならChatflowです。ChatbotとChatflowはどちらも会話形式ですが、Chatflowはメッセージごとにノードで組んだフローを走らせてから応答します。公式チュートリアルの顧客サポートボットは、質問分類ノードで「無関係な質問」「Difyに関する質問（＝自社製品についての質問）」「技術用語の説明」「コミュニティ参加」に振り分け、無関係な質問と参加案内はLLMを通さずAnswerノードで即答させる構成を採っています。LLMを通さない分岐を作れることが、コストと誤回答の両方を下げます。

WorkflowとChatflowはノードキャンバスを共有しますが、開始と終了のノードが違います。Workflowは User Input または Trigger で始まり Output ノード（任意）で終わるのに対し、**Chatflowは User Input で始まり Answer ノードが必須**です。そしてChatflowにTriggerはありません。公式は理由を「Chatflows always start from a user message, so they don’t have Triggers」と明記しています。スケジュール実行やWebhook起動をしたいならChatflowではなくWorkflow側の設計になります。ノードの組み方は[Difyワークフローの作り方と使い方｜ノード選定・ループ・トリガーを実装手順で解説【2026年版】](/tech/details/4679/)で扱っています。

### Agent／New Agent：ツール選択をモデルに任せる場合

Agentは「Chat-style apps where the model can reason, make decisions, and use tools autonomously」で、こちらが手順を設計する代わりにモデルが次の行動を決めます。データを取得して集計してグラフを作る、といった手順が固定できないタスク向けです。逆に言えば、社内規程を答えるだけのボットにAgentを使う理由はありません。応答経路が毎回変わるため、回答品質の再現性が落ちます。

選び方の判断はこう置けます。手順が固定できるならChatflow、手順が要らないならChatbot、手順が事前に決められないときだけAgent。迷ったらChatbotで始めるのが安全で、その根拠は後戻りのしやすさにあります。

Difyには管理画面からアプリをフロー型へ変換する機能があり、対象は Chatbot（内部モード名 `chat`）と Text Generator（同 `completion`）の2つです。ただし変換は既存アプリを書き換えるのではなく**新しいアプリとして作り直される**ため、公開URLやAPIキーは引き継がれません。そして**Agent（同 `agent-chat`）はこの変換の対象外**で、サーバー側が受け付けるモードの一覧に含まれず「App mode is not in the supported list」として拒否されます。なおこの変換はブラウザのログインセッションで動く管理画面用APIなので、後述する `app-` で始まる公開APIキーからは呼べません。最初にAgentを選ぶと、あとからフロー型に組み替えたくなったときは手作業での作り直しになります。

### 会話履歴の上限（500メッセージ／2,000トークン）と切り捨ての挙動

ChatbotとAgentの公式ドキュメントには、同じ一文が置かれています。「Chatbots keep up to 500 messages or 2,000 tokens of history per conversation. If either limit is exceeded, the oldest messages will be removed to make room for new ones.」つまり**500メッセージと2,000トークンのどちらか一方でも超えた時点で、古いメッセージから順に落ちる**という仕様です。

実務で先に効くのはトークン側です。日本語で数往復すれば2,000トークンは容易に超えるため、「さっき言った条件を踏まえて」という参照は途中から成立しなくなります。前提条件を会話の途中で保持させたい場合は、履歴に頼らずChatflowの会話変数（Variable Assigner ノード）に退避させるか、プロンプト変数として会話開始時に固定してしまうのが確実です。この上限は日本語の解説記事でほぼ触れられていませんが、「長く話すと指示を忘れる」という不具合報告の実体はたいていこれです。

## ゼロから作る手順：アプリ作成からナレッジ連携まで

### アプリ作成とプロンプトに入れる3要素

スタジオから「Create from Blank（最初から作成）」を選び、上で決めたアプリ種別を指定します。プロンプトで押さえるのは、役割（誰として答えるか）・出力形式（構造や長さ）・制約（何を答えないか）の3点です。とくに社内ボットでは「ナレッジに書かれていない場合は推測せず、担当窓口を案内する」という制約を明記しないと、LLMが一般論で埋めてしまいます。

プロンプトが書けないときは「Generate」でLLMに草案を作らせられます。生成のたびにバージョンとして保存されるため、比較して戻すことができます。右側のプレビューでは「Debug as Multiple Models」で最大4モデルを同時に走らせて出力を比較できるので、モデル選定はここで済ませます。モデルプロバイダーはDify 1.0以降プラグインとして追加する形式なので、目的のモデルが一覧に無い場合は[Difyのプラグインがインストールできない原因と対処法【署名検証・容量・バージョン】](/tech/details/7098/)を先に確認してください。

### ナレッジ作成時に決めるチャンク設定と索引方法

「ナレッジ」からナレッジベースを作成し、ローカルファイル・Notion・Webサイトのいずれかを取り込みます。Webサイトから取り込む場合は Firecrawl か Jina Reader を使います。設定場所は画面右上のアバターから「DataSource」を開き、各プロバイダーの「Configure」でAPIキーを登録する流れです。**コードは一切書きません**。Firecrawl側ではサブページを辿るか、クロール上限ページ数、最大深度、除外パス、対象パス、抽出範囲を指定できます。なお公式チュートリアルは、Webサイト同期の処理上限を50ページと案内しています。社内ポータル全体を丸ごと入れる用途には足りないため、ナレッジベースを分ける前提で設計してください。

アップロード後の分割設定では、既定の自動分割のまま進めるかカスタムで規則を指定します。索引方法は High Quality と Economical の二択で、**High Qualityは埋め込みモデルのトークンを消費し、Economicalはチャンクごとに10個のキーワードを使う転置インデックスなのでトークンを消費しません**。ただし後述するとおり、容量を食うのはHigh Qualityだけです。ここが「先に決める」項目である理由は不可逆性にあります。**High Qualityで作成したナレッジベースは、あとからEconomicalへ戻せません**（逆方向のEconomical→High Qualityは設定画面から可能です）。検索方式をベクトル検索・全文検索・ハイブリッド検索から選べるのも**High Qualityを選んだ場合だけ**で、Economicalは転置インデックス一択になります。公式は最も一般的な選択としてハイブリッド検索を挙げています。ナレッジをどこまで作り込むべきか、そもそもRAGで足りるのかという判断は[RAGとファインチューニングの違いと使い分け｜判断基準とコストで選ぶ2026年の実装方針](/tech/details/4650/)で整理しています。

### 検索設定2層（ナレッジ側／アプリ側）の効き方

回答精度が上がらないときに見落とされがちなのが、検索設定が2箇所にあることです。公式は両者を連続するフィルタと説明しています。**ナレッジベース側の設定が候補の母集団を決め、アプリ側の「Retrieval Setting」がその結果をさらに並べ替えるか絞り込む**という関係です。片方だけ調整しても効かない理由がここにあります。

アプリ側で触れるのは次の値です。Weighted Score は意味的な類似とキーワード一致の重み配分ですが、**追加した全ナレッジベースがHigh Quality索引の場合しか選択できません**。Economicalのナレッジを1つ混ぜた時点で選択肢から消えます。Rerank Model は既定で無効で、有効にすると検索で返ったチャンクを関連度で並べ替えます。**Top K（既定3）と Score Threshold（既定0.5）はリランク段階でのみ効く値なので、Rerankモデルを追加・有効化していないと設定しても反映されません**。Rerankモデルを指定した場合、Top K はそのモデルの最大入力量に応じて自動調整されます。Score Threshold は下回った結果を除外する最低スコアで、無関係な文書が混ざるなら上げ、そもそも何も引けないなら下げます。

ナレッジベースが大きい場合は、メタデータによる絞り込みを有効にすると検索対象を特定文書に限定できます。人事規程と技術文書を同じナレッジに入れているなら、これを設定しないと精度は安定しません。

### 公開前のリトリーバルテストによる根拠確認

ナレッジベースのドキュメント画面にある「Retrieval Testing（リトリーバルテスト）」で、クエリを入れて実際に引かれるチャンクを確認します。ここで想定した段落が出てこないなら、原因はプロンプトではなく分割か索引です。公式も、分割された内容の連続性が崩れていると検索結果に影響するため、目視で確認して不要な断片は無効化・削除するよう案内しています。ボットの応答を直す前にこちらを直すのが順序です。

## 社内ナレッジを載せる前に確認する容量とレート制限

社内利用でつまずくのはたいてい機能ではなく枠です。ここは数値が公開されているので、載せる文書量から先に逆算できます。

| 項目           | Sandbox | Professional | Team      |
| ------------ | ------- | ------------ | --------- |
| ナレッジ容量       | 50 MB   | 5 GB         | 20 GB     |
| ナレッジ操作レート    | 10 回/分  | 100 回/分      | 1,000 回/分 |
| チームメンバー      | 1 名     | 3 名          | 50 名      |
| アプリ数         | 5       | 50           | 200       |
| ナレッジ文書数      | 50      | 500          | 1,000     |
| 年額（1ワークスペース） | 無料      | $590         | $1,590    |

容量の計算方法には注意が要ります。消費するのは**元ファイルのサイズではなく、生成されたベクトルの量**です。チャンクが細かいほどベクトルが増え、埋め込みモデルの次元数が大きいほど1チャンクあたりの消費が増えます。公式はOpenAIの `text-embedding-3-large` が `text-embedding-3-small` の2倍近い容量を使う例を挙げており、結果として索引後の使用量が元ファイルサイズの数倍になることがあると明記しています。親子チャンク（Parent-child mode）では子チャンクがそれぞれベクトル化されるため、さらに増えます。

上限を超えるアップロードは、索引処理の前に判定されて弾かれます。このときドキュメント一覧には残るものの索引されないため、一覧に見えているのに検索に出てこないという状態になります。回避策はファイル分割、チャンクサイズを上げてチャンク数を減らす、プランを上げるの3つですが、チャンクを大きくすると1件あたりの取得文が長く曖昧になるトレードオフがあります。Economical索引は容量を消費しないため、検索精度を落としてよい参考資料をこちらへ寄せるのは有効です。ただしこれは**上限に達する前の設計としてのみ成立します**。いったん上限に到達すると、アップロード・チャンクの追加編集・アーカイブ復元・チャンク設定変更に伴う再索引が、Economical索引のナレッジベースを含めて一律で止まるためです。

レート制限が効く操作は公式に18項目が列挙されており、ナレッジベースの作成・削除・設定更新、ドキュメントのアップロード・削除・更新・有効化・無効化・アーカイブ・復元・処理の一時停止と再開、セグメントの追加・削除・更新・一括インポート、ヒットテストの実行、そして**アプリやワークフローからのナレッジ検索**が含まれます。最後の1項目が社内チャットボットには決定的です。**社員がボットに質問するたびに1回として数えられる**ため、Sandboxの10回/分は文書の一括投入時だけでなく利用のピーク時にも触れます（複数経路の同時検索は1リクエストとして数えられます）。公式もSandboxで1分間に10回のヒットテストを行うと次の1分間これらの操作が制限される例を挙げています。

## 社内へ公開する方法と、ユーザーごとの分離仕様

### リンク・iframe・チャットバブルの使い分け

「Publish」から公開すると、まずWebアプリのURLが発行されます。社内ポータルにURLを貼るだけならこれで完了です。ページに埋め込む場合は、アプリの「Embed Into Site」で発行されるトークンを使います。

常時表示したいならiframeです。次のタグを置くだけで、JavaScriptの設定なしにページの一部として組み込めます。

```
<iframe
  src="https://udify.app/chatbot/YOUR_APP_TOKEN"
  width="100%"
  height="600"
  frameborder="0">
</iframe>
```

一方、既存ページを邪魔したくないならフローティングボタン型のチャットバブルで、`window.difyChatbotConfig` に token を渡して埋め込みスクリプトを読み込みます。この設定オブジェクトでは、表示位置（`containerProps`）、ドラッグ可否（`draggable` / `dragAxis`）に加えて、アプリの入力変数を `inputs` で事前設定できます。社員の所属部署をログイン情報から埋めておけば、利用者に部署を選ばせる手間が消えます。

### ワークスペースの4ロールと招待リンクの有効期限

社内に配る前に決めるのが権限です。ワークスペースのロールは Owner（1ワークスペースに1名・全権）、Admin（メンバーとモデルプロバイダーの管理＋Editorの権限）、Editor（アプリとナレッジベースの作成・編集・削除）、Normal（**公開済みアプリの利用のみ**）の4種類です。ボットを使うだけの社員はNormalで足ります。アプリを壊されたくないなら、ここを絞るのが最初の防御線です。

メンバーを追加できるのは Owner と Admin で、メールアドレスを入力すると招待リンクが送られます。**招待リンクの有効期限は72時間**で、期限切れの場合は招待し直しになります。ロール変更は対象者がサインイン中でも次の操作から反映され、メンバーを削除してもその人が作ったアプリとナレッジベースはワークスペースに残ります。なおOwnerのロール変更は所有権の移譲でのみ可能で、移譲するとOwnerだった側はAdminになります。無料のSandboxはメンバーが1名までなので、そもそも権限を分担できません。

### APIのuserパラメータによる会話・ファイルの可視範囲

自社の既存システムに組み込む場合は、公開されたAPIを直接呼びます。ここで安全面の要になるのが `user` パラメータです。仕様上、**会話・メッセージ・ファイルは同じ `user` を持つリクエストからしか見えません**。逆に言えば、全社員のリクエストに同じ固定値を渡す実装にすると、会話履歴が全員から参照可能な状態になります。社内チャットボットをAPI経由で組む場合、ここを社員IDに紐づけるかどうかが実質的なアクセス制御になります。

## APIから呼ぶときの実装：公式Python SDKは2023年で止まっている

Difyの連携方法を調べると `import dify_sdk` で始まるPythonコードが多く出回っていますが、**このコードは動きません**。PyPIの `dify_sdk` は第三者（github.com/cruldra/dify-sdk）が公開しているパッケージで、配布wheelのトップレベルモジュールは `dify` です。インストールしても `import dify_sdk` は ModuleNotFoundError になります。そしてこの第三者SDKのAPIは `from dify import AdminClient, Dify` による非同期呼び出しで、よく見かける `create_bot()` や `add_faq()` といったメソッドはどこにも存在しません。

公式の `dify-client` はPyPIに存在しますが、最新版は 0.1.10 で公開日は2023年11月15日、以降更新されていません。中身も `DifyClient` / `ChatClient` / `CompletionClient` の3クラスだけで、ベースURLは `https://api.dify.ai/v1` にハードコードされています。セルフホスト環境を向き先にできないため、実質的に選択肢から外れます。**現時点で確実なのはREST APIを直接叩く実装です。**

アプリ画面の「APIアクセス」で `app-` で始まるキーを発行し、Bearerトークンとして送ります。

```
import requests

API_BASE = "https://api.dify.ai/v1"
API_KEY = "app-XXXXXXXXXXXXXXXXXXXXXXXX"

res = requests.post(
    f"{API_BASE}/chat-messages",
    headers={
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json",
    },
    json={
        "query": "経費精算の締め日はいつですか",
        "inputs": {},
        "response_mode": "blocking",
        "user": "emp-0142",
        "conversation_id": "",
    },
    timeout=60,
)
print(res.status_code, res.json())
```

キーが不正な場合、このコードは `401 {'code': 'unauthorized', 'message': 'Access token is invalid', 'status': 401}` を返します（2026年8月18日に実リクエストで確認）。まずこの応答が返ることを確認できれば、エンドポイントとネットワーク経路は正しく、あとはキーの問題だと切り分けられます。

`conversation_id` は空文字または省略で新規会話になり、応答に含まれる値を次のリクエストへ渡すと会話が継続します。過去の会話を再開したい場合は会話一覧APIからIDを取得します。

### Agent／New Agentアプリでblockingが400になる条件

ここに明確な落とし穴があります。`response_mode` は**省略時 blocking**ですが、**AgentおよびNew Agentアプリは streaming にしか対応せず、blocking でのリクエストは400で失敗します**。エラーコードは `bad_request`、メッセージは「Agent App only supports streaming response mode.」です。上のコードをそのままAgentアプリに向けると必ず落ちるので、Agentを選んだ時点でSSEを受け取る実装が前提になると理解しておく必要があります。

blockingにも別の注意があります。公式はDify Cloudについて、応答がエッジプロキシのタイムアウト内に返らないと接続が切られる可能性があると明記しており、長い生成では途中で切断されます。推奨は streaming です。New Agentアプリ特有のエラーとしては、Agentが紐づいていない場合の `invalid_param`、紐づいたAgentに公開済みバージョンが無い場合の `agent_not_published` もあります。

## クラウドとセルフホストの判断軸：社内データをどこまで出せるか

社内チャットボットで必ず問われるのが、規程や顧客情報をDify Cloudに置いてよいかという点です。ここは機能比較ではなく、データの所在で決める問題です。持ち出しが許容できないならCommunity Edition（オープンソース版）を自社インフラに立てる一択で、逆に許容できるならCloudの方が運用負荷が圧倒的に軽くなります。中間はありません。

セルフホストの最小要件は CPU 2コア以上、RAM 4GiB以上、Docker Compose 2.24.0以降です。macOSのDocker Desktopで動かす場合は、仮想マシンに仮想CPU 2つとメモリ8GiBを割り当てるよう案内されています。WindowsのWSL 2環境では、ソースコードとデータをWindows側ではなくLinuxファイルシステムに置く必要があります。起動後は `http://localhost/install` で管理者アカウントを作成します。

ただし検証機と本番は別問題です。公式がこれらを示しているのは「minimum system requirements（最小システム要件）」としてであり、本番相当の負荷を想定した推奨値ではありません。ナレッジ検索と埋め込み処理が同時に走る運用では、この値を出発点として実測で積み増す前提になります。AWS上に本番相当で構築する手順は[DifyをEC2上に構築するための基本手順と事前準備](/tech/details/2725/)に、可用性を求める構成は[AWS EKSにDifyを導入するための事前準備と環境構築のポイント](/tech/details/7097/)にまとめています。なお、セルフホストにしてもモデルAPIを外部プロバイダーに向ける限りプロンプトは社外へ出ます。ここを塞ぐには自社ホストのモデルを使う設計が別途必要で、「セルフホストにしたから安全」という整理は成り立ちません。

## よくある質問

### Difyの読み方は？

開発元LangGenius, Inc.の日本語向けサイトおよび日本語ドキュメントを確認した限り、カタカナ表記は掲載されておらず、公式表記は一貫して英字の「Dify」です。日本語の解説記事では「ディファイ」と「ディフィー」が併存しており、どちらか一方を公式読みとする根拠は見当たりません。社内資料やスライドで表記を統一する必要がある場合は、読み仮名を付けず「Dify」のまま扱うのが無難です。

### Difyでチャットボットを作るのにコードは必要ですか？

不要です。アプリ作成、プロンプト設定、ナレッジのアップロード、Webサイトのクロール設定、公開まですべて画面操作で完結します。FirecrawlやJina ReaderのAPIキー登録も、アバターメニューのDataSource画面に貼り付けるだけです。コードが必要になるのは、自社システムからREST APIで呼び出す場合と、Workflow内でコード実行ノードを使う場合に限られます。

### 無料のSandboxプランだけで社内チャットボットを運用できますか？

試作までなら可能ですが、常用は現実的ではありません。ナレッジ容量が50MBしかなく、High Quality索引では元ファイルサイズの数倍を消費するため、社内規程を数十ファイル入れた段階で上限に達します。加えてナレッジ操作のレート制限が10回/分で、初回の一括投入で制限に触れます。さらにワークスペースのメンバーが1名までなので、管理者を分担することもできません（アプリ数5・ナレッジ文書数50の上限もあります）。文書を継続的に追加する運用に入るなら、5GB・100回/分・3名のProfessional以上が実質的な下限です。

### Difyの類似サービスにはどのようなものがありますか？

ノーコードでLLMアプリを組む領域では、Microsoft Copilot Studio、Flowise、Langflow、n8nなどが比較対象に挙がります。Difyの特徴は、ナレッジベース・ワークフロー・アプリ公開・APIが1つの画面に統合されている点と、Community Editionを自社インフラに置ける点です。オープンソースかつセルフホスト可能という条件で絞ると、選択肢はFlowiseやLangflowなど数えるほどになります。業務別のボットではなく社内向けの汎用チャット画面が要件なら、[LibreChatによる社内AIチャット基盤の構築と採用判断](https://www.issoh.co.jp/tech/details/17653/)も比較対象に入ります。

### 会話の途中で前の指示を忘れてしまうのはなぜですか？

ChatbotとAgentが1会話あたり500メッセージまたは2,000トークンまでしか履歴を保持しない仕様のためで、設定値ではないので緩められません。Chatflowの会話変数へ退避させる方法をとる場合、その値は会話変数の一覧・更新APIから外部システム側でも読み書きできるため、基幹システムに持たせた申請状況などを会話をまたいで参照させる設計にできます。

## 関連記事

- [Difyワークフローの作り方と使い方｜ノード選定・ループ・トリガーを実装手順で解説【2026年版】](/tech/details/4679/)
- [Difyのプラグインがインストールできない原因と対処法【署名検証・容量・バージョン】](/tech/details/7098/)
- [RAGとファインチューニングの違いと使い分け｜判断基準とコストで選ぶ2026年の実装方針](/tech/details/4650/)
- [DifyをEC2上に構築するための基本手順と事前準備](/tech/details/2725/)
- [AWS EKSにDifyを導入するための事前準備と環境構築のポイント](/tech/details/7097/)

---

出典: [Difyでチャットボットを作る手順｜種別の選び分けと社内ナレッジ設定【2026年版】](<https://www.issoh.co.jp/tech/details/2758/>)（株式会社一創）