Dynabook社のソリューション事業を支えるOmluc ～ Dynabook × Omlucが描く、生成AI時代の現実解とDifyの可能性 Part2

Dynabook社のソリューション事業を支えるOmluc ～ Dynabook × Omlucが描く、生成AI時代の現実解とDifyの可能性 Part2

コラム

2026/03/24

生成AIは、もはや一部の先進企業だけのものではなく、能力と応用面の進化が加速度的に進んでいる状況です。一方で、多くの企業が「試したが業務に定着しない」「PoCで止まっている」という壁に直面しているのも事実です。そうした状況で、ハードウェアを起点に、生成AIを “業務の現場に実装する" という独自のアプローチを進めているのがDynabook株式会社です。

本対談Part2では、Dynabookでソリューション事業を牽引する宮入氏・麻生氏と、Omluc代表岸田が、Difyの価値と可能性について語り合いました。

Difyの本質的な価値とは？

岸田（Omluc）

本日はこれまでの両社の取り組みを踏まえて、改めてDifyの強みや、業務活用のリアルについてお話しできればと思っています。まず、Dynabook社がDifyに注目されたポイントから伺えますか。

宮入氏（Dynabook）

生成AIが一気に伸びてくる中で、「Dynabookとして、生成AIをお客様向けのソリューションとしてどのように提供するのか」が大きな課題でした。生成AIを使ったアプリを作る技術自体が難しく、知見を持った社内の人材も限られていました。その中で、Difyを使えば生成AIをフル活用したアプリケーションを比較的簡単に作れる点、特にワークフローを軸に業務効率化ができる点に大きな可能性を感じました。

岸田

まさにそこがDifyの本質だと思っています。生成AIエンジニアは希少でコストも高いですが、Difyを使えばノーコードで一定レベル以上のアプリが作れます。しかも、単に「早く作れる」だけでなく、最初からベストプラクティスに近い状態まで持っていけるのが大きいですね。

宮入様

そうですね。ゼロからフルスクラッチで作ろうとすると、設計の正解を見つけるまでに相当な時間がかかります。その点、Difyは「この形で作ればまず失敗しにくい」という道筋が見えているのがありがたいです。

麻生様（Dynabook）

開発ツールとして見ても、Difyはかなり優秀ですね。受託開発のようなケースでも、LangChainでゴリゴリ書くと数か月かかるものが、Difyなら数日で形になることもあります。スピードだけでなく、プラットフォームとしての品質が担保されているのも大きなメリットだと思います。

岸田

加えて、Difyはアップデートのスピードも非常に速いです。ほぼ毎週のように改善が入り、プラグインやトリガーなど、現場の要望を反映する形で進化しています。これはオープンソースで、世界中のユーザーから上がってくるIssueを取り込んでいるからこそだと思います。

宮入様

特に印象的なのが、プラグインやカスタム拡張の考え方ですね。必要なところだけPythonで拡張して、それ以外は標準機能を使う。このバランスがとても現実的だと感じます。

岸田

Difyの面白いところは、PoCの速さと最終的なカスタマイズ性を両立している点です。一般的なPoCツールは早いけれど作り直しが前提、というケースが多い中で、Difyはそのまま本番運用まで持っていける設計になっています。しかも、LLMOpsの思想が最初から組み込まれているので、ログやメトリクスを取りながら改善を回せます。この点が本質的に重要だと考えています。

Difyの現在地と今後の可能性

麻生様

昨年末に追加されたトリガー機能も、業務活用という意味では大きいですよね。

岸田

はい。RAGの高度化に役立つナレッジパイプラインに加えてトリガーが出たことで、Difyは「現場がAIアプリをつくって活用するための必須条件が揃った」と感じています。定期実行やイベントを起点にAIを動かせることで、人が使いに行かなくてもAIが価値を生み続ける状態を作れます。これは、AIが業務に定着しない問題への一つの答えだと思っています。今年2月にリリースされたHuman in the Loopという、ワークフローの中に人の判断や承認、確認プロセスが織り込める機能が加わりさらに強力になったと思います。

宮入様

実際にDynabookでも、Difyのトリガー機能を使って定期的にAIニュースを更新して共有するとか、月次レポートを自動で作成するなどに活用しています。こういうところで業務効率の大きな改善ができるという可能性を実感しています。人がやると続かないことを、AIが淡々とやってくれるのは大きいですね。

岸田

まさにそこです。AI×定期実行は「継続」が得意です。人が行うと努力が必要だったり、面倒と思うようなところをAIが補うことで、結果的に業務全体が安定的に運用できるようになります。これまでRPAが担っていた業務プロセス自動化も、Difyと生成AIの進化で徐々に置き換わっていくのではないかと考えています。そのような見方も含めてDifyのトリガーというのはターニングポイントだったと思います。アンビエント・エージェントという考え方です。

Difyがユースケース集になり、企業独自の資産になるという未来像

宮入様

Dynabookの場合、例えばPCの開発業務ひとつとってみても、世の中の様々な安全性・信頼性、電波・通信、インターフェース、環境などの規格が日々更新されていて、その情報を人が追い続け、要約して開発チームに展開する。こういうことも非常に労力が必要で、Difyが自動で更新情報を見に行ってそれを要約して展開してくれるととても助かります。他にも、ユーザー様から沢山のフィードバックいただいていますけど、データが膨大すぎて十分に使いきれない。このような資産があるのに、活用しきれなかったところを活用できるようにする、見えなかったところをちゃんと見える化することでより良い製品を作っていくための活動につなげていける。こういう使い方もできるのかなと考えています。ところで、外部システム連携についてはいかがでしょうか。基幹システムやSaaSとの接続は、企業導入では避けて通れない課題です。

岸田

技術的には、外部システムやツールとの連携についてはDifyのプラグインやMCP対応でかなりの部分が解決できている状態です。むしろ課題は社内ネットワークやガバナンスなど、インフラや制度の部分ですね。ただ、Difyの良いところは、連携が必要なシステムやツールが出てきてもプラグインを作れば連携ができる点です。技術以上に大事なのが、ではどういうユースケースなのかという点です。AIエンジニアは技術には当然強いですが、業務のことはよく分からない。業務のことをよく分かっている人がユースケースを考え、Difyを使って実装していく。このような積み重ねが、将来的に業務ユースケースをDify上に蓄積していくことにつながり、大きな資産になると考えています。

麻生様

「業務を一番理解している非エンジニアがDifyを使う」 という考え方は非常にしっくりきますね。

岸田

はい。Difyはハブなので、業務やルールで回っている仕事はかなりの部分を置き換えられます。一方で、非合理な判断や「それでもこれをやりたい」という意思決定は人間に残る。その分業が、現実的な人とAIの共存なのだと思います。