第一章：なぜ私はこの取り組みを始めたのか？——日常業務からの「無言の抗議」
あなたも会社でIT運用、内務サポート、カスタマーサポートを担当しているなら、きっとよくわかるでしょう——毎朝目が覚めると、さまざまなチャネルから「ちょっと見てください」というリクエストに埋もれてしまう。
メールから、企業用WeChatから、直接声をかけてくる人から、そしてなぜか私のプライベートチャットに流れ込んでくるものまで。
多くの時間が「問題がどこにあるのか」を探すことにつぎ込まれていた。
さらに厄介なのは：
-
一部の人は説明が非常に曖昧で、謎かけのような感じ
-
一部の人はメッセージを機関銃のように送り、情報がガラスの破片のように細かく散らばっている
-
問題がOutlookの会話スレッドに散らばっており、まったく集中管理されていない
ある日、ふと閃いた：
もし一つの入口があって、
ユーザーが普段の会話のように問題を説明でき、
AIが自動的に問題情報を抽出して、
それをシステムに送り込み、
ITチームが「情報を探す」ことから「問題を解決する」ことに解放されるなら、
どれほど素晴らしいだろう。
これが、この探求を始めた理由です。
今、誰もが「誰でも開発者になれる」「誰でもAIアプリを構築できる」と言っています。
私も、コードを書かずにこれを実現できるか試してみたかった。
大それた物語などありません。ただ単純に：毎日の仕事を少しでも楽にしたい。
第二章：第一歩、人間の言葉を「理解できる」入口が必要——Dify ChatFlow
実際に市場のAIワークフローツールを調査し始めたとき、いくつかの注目製品を試してみました：
機能は強いが学習コストが高いもの、データの扱いに不向きなもの、自分でUIを構築する必要があるものなど。
最終的にDifyを選んだ理由は：
-
対話型のフローエディターが非常に直感的
-
構築のハードルが低く、ほぼコードを書く必要がない
-
デプロイコストがゼロで、開発者に頼る必要がない
-
ChatFlowの入口をフロントエンドページに直接埋め込めるため、自分でチャットUIを書く必要がない
要するに、「あなたがロジックを考えてくれれば、あとは私が実現する」というツールです。
そこで、まずDifyを使って最初の重要な問題を解決することにしました：
「完全なチケットをエレガントに収集するにはどうすればいいか？」
2.1 AIに「チケット情報収集担当者」としての仕事を与える
LLMノードで、以下のようなsystem promptを記述しました：
役割設定：あなたは会社のITチケットサービスアシスタントです。あなたの仕事は、従業員がIT修理チケットを提出するのを助けることです。
必要な情報リスト：
- 問題の説明 (Description)
- デバイスの種類 (Device Type)
- 緊急度 (Priority)【低、中、高、緊急】
- 申請者 (Applicant)
実行ロジック：
ユーザーの入力に上記の必要な情報がすべて含まれているかを確認します。
情報が不足している場合：不足している部分を丁寧に質問し、情報を捏造しないでください。
情報がすべて収集された場合：収集された情報に基づいて、以下の標準フォーマットのJSONのみを出力してください：
Ticket_Complete_JSON: {"title": "...", "description": "...", "device": "...", "priority": "..."}
注意：情報が完全に収集された場合のみ、Ticket_Complete_JSONを出力してください。それ以外の場合は、ユーザーとの対話を続けます。
モデルに明確に伝える：
いつ対話を続け、いつ正式に「チケットを受付ける」か。
モデルキーがない場合は、DeepSeek APIプラットフォームhttps://platform.deepseek.com/usageで10元をチャージしてキーを取得することをおすすめします。個人利用ではほぼ使い切れない量です。
2.2 もう一つの分類器で判断：AIは会話中か？それとも情報収集完了か？
ChatFlowに「応答分類器」を追加しました。
このノードの役割は：
-
AIがまだ自然な対話中 → 内容をそのままユーザーに返して対話を続ける
-
Ticket_Complete_JSONが出現 → 「情報が完全に収集された」→ 後続処理ブランチに進む
この判断点は非常に重要で、全体のフローを「本物のチケット入口」のようにするための鍵です。
2.3 次のステップ：「データはどこに置く？」
この時点で構造化されたチケット情報が得られましたが、それを格納するデータコンテナが必要でした。
いくつかの方向を試してみました：
-
-
Excelを使う？脆弱すぎて長期的な解決策ではない。
-
自前でデータベースを構築？問題を解決したいだけで、新プロジェクトを立ち上げたいわけではない。
-
悩んでいたところ、Difyのツールライブラリで「HAP」のプラグインを発見しました。
プラットフォームにネイティブに統合されているので、試しに登録して使ってみたところ：
-
-
学習コストほぼゼロ
-
実際に無料で始められる
-
営業に権限を申請する必要がなく、直接アカウントを登録できる（これは高評価
） -
さらに重要なのは：これは単なる「フォームツール」ではなく、本物のデータベースである
-
当初はただデータを置く場所が欲しかったのですが、HAPを使い始めた瞬間、私は気づきました：
私の期待はあまりにも保守的だった。
第三章：データを置く場所を探していたら、HAPが「フォームツール」ではなく「データ基盤」であることに気づいた
初めて明道雲HAPを開いたとき、正直なところ：
ただチケット情報を置く場所が欲しかった。
本当に、それだけの素朴なニーズでした。
しかし、アプリケーションやテーブルを作り始めたとき、私の感想は「結構便利だな」から「あ、これもできるの？」、そして最終的には——
「なんでこんなに期待以上に優れているの？？？」
3.1 アプリケーションの新規作成：HAPへの第一歩体験
HAPに入ったら、まず製品のナビゲーションに従って左側の【アプリケーション】を見つけ、【新規アプリケーション】をクリック。
アプリケーション名は「チケット管理」と入力。作成が成功すると、空のアプリケーションページに移動します。
ここで最初のワークシートを作成します。「空白から作成」をクリックすると、ウィンドウが表示され、2つのオプションがあります：
-
AIを使って作成
-
Excelからインポートして作成
もともとは自分でフィールドを並べるつもりでしたが、「AIを使って作成」をクリックしてみることにしました。フィールドを並べるのは最も時間がかかる作業なので、自動生成できれば非常に楽です。
3.2 HAPのAIによるフォーム生成：私が思っていたより「完全」
AIダイアログに入ると、推奨オプションの内容は「チケット管理」に基づいて生成されているようで、細部まで丁寧です。
最初の推奨オプションをクリックすると、右側のフォーム構造がすぐに生成されました。
フィールドの数は私が予想していたよりずっと多く、しかし「詰め込み式」ではなく、企業内の流れに非常に合ったものでした：チケット番号、種類、状態、優先度、提出時間、処理説明、添付ファイル……「担当者」「担当部門」まで考慮されています。
正直なところ、私はその時点でそこまで細かく考えていなかったのですが、AIが「通常の企業運営に必要なフィールド」をかなり完璧に列挙してくれていました。
AI機能への信頼感は、このような予想を超える回答によって構築されるべきです。
もちろん、このデモではこれほど完全なフィールドは必要ないので、ヒントをhoverしてフィールドの説明を確認し、一時的に使わないフィールドを削除しました。全体的に調整しやすく、とてもスムーズでした。
3.3 フォームを保存した後、HAPが単なるフォームツールではないことに気づいた
フォームを保存した後、システムは「顧客情報」「機器情報」などの関連テーブルを追加するか尋ねてきました。
最初は一般的なテンプレートの推奨だと思っていましたが、中を見てみると：
HAPのワークシートは、構造化されたデータテーブルであり、関連性はデータベースのロジックと一致しています。
違いは、これらの「データベースモデリングステップ」を、普通の業務ユーザーでも理解できる操作方法にパッケージングしていることです。
この感覚は、まるで——
一瞬前までただテーブルを作ろうとしていたのに、次の瞬間システムが教えてくれる：
「ついでに業務データモデルも一緒に構築しませんか？」
これにより、その定位を再評価しました。単なる「データを表示する」ものではなく、「業務データ構造を蓄積する」ものです。
私のように、軽量で複雑な業務まで拡張可能なツールが必要な人にとっては、この方向性は大きなプラスです。
3.4 もう一つ「顧客情報テーブル」を作成：dify → HAPのチケット闭环の準備
後でdifyがチケットを作成する際により完全な情報を書き込めるように、「顧客情報」テーブルを作成しました。
「顧客情報」と入力すると、AIが生成するフィールドも同様に完全で、顧客名、電話、メール、備考、顧客タイプ……必要に応じて不要なフィールドを削除し、デモで使用する部分だけを残しました。
この時点で：
-
チケット情報テーブル
-
顧客情報テーブル
が準備でき、2つのテーブル間で簡単に関連付けを設定できます。
これで、HAP側の「データ基盤」は構築完了。次にdifyに戻って、この2つのシステムをつなぎます。
第四章：DifyからHAPへ書き込む——チケットが真正に「実現」する一歩
チケット表構造がHAPで準備された後、次のステップは、ユーザーが入力した自然言語を実際にHAPのチケットレコードとして「実現」させることです。
私にとっては、この部分は想像以上に簡単でしたが、初めて手を出したときは少しハマりました。ここではそのプロセスを共有します。
4.1 パラメータ抽出：AIの構造化結果をデータベースに書き込めるフィールドに分解
モデルが意図分類後に返すのは完全な構造化JSONですが、これは「全体的」なものであり、HAPの新規レコードツールは「個々のフィールド」に対応する値を必要とします。
そこで、私は「パラメータ抽出器」を追加しました。
その役割は非常にシンプル：
- 全体の構造化JSONを個別の変数に分解する
（例：Title、Description、Applicant、Priority……）
- 後続のノードで個別に記入できるようにする
ここでは追加のロジックは必要なく、単純なフィールド分解です。
4.2 核心ノード：HAP「新規レコード」—— チケットを実際にデータベースに書き込む
全体のブランチの核心ノードはHAP-新規レコードです。
（1）ツールの選択：HAP → 新規レコード
ツール検索ボックスに「hap」を入力 → インストール
**「新規レコード」**を選択します。
（2）AppKey / Signの入力
新規レコードには認証が必要です。
HAPページの右上隅のメニューを開く → API開発ドキュメント、そこにはアプリケーションの：
-
AppKey
-
Sign
が表示されます。
それらをノード設定に記入します。
（3）ワークシートIDはどこから来る？
ワークシートIDもAPIドキュメントにあります。
フォームの《フィールド対照表》ページに入ると、上部に：
ワークシートID：xxxxxxxxxxxxxx
と表示されます。
（4）重点：「レコードフィールド（オブジェクト）」の入力方法は？
これは最も詰まりやすいステップですが、実は非常に楽です。
HAPが要求するレコードフィールドの構造は以下の通りです：
{
"フィールドID": "書き込みたい値",
"フィールドID2": "値2"
}
フィールドIDはAPIドキュメントの《フィールド対照表》から直接コピーできます。
手動でJSONを組み立てるのは非常に面倒なので、以下の2つの内容を大規模言語モデルに送りました：
-
フィールド対照表のスクリーンショット
-
書き込みたいフィールド（Title、Description、Applicant、Priorityなど）
モデルに最終的なJSONテンプレートを生成させました。
このJSONを「レコードフィールド（オブジェクト）」に記入すれば、全体のフローがつながります。
第五章：システム導入後の実際の効果と、予想外の感想
全体のフローが動くようになると（Difyが「人間の言葉を理解」し、HAPが「データを保持・管理」）、私は対話入口をフロントエンドページの独立したチケット入口に埋め込みました。
従業員がページを開くと、シンプルなチャットボックスが表示されます：
問題を説明 → AIが追加情報を質問 → 自動的にチケットを作成。
全体の学習コストはほぼゼロです。
私たちITチームにとって、最も顕著な変化は：
-
チケットがメールに散らばらなくなった
-
データが構造化された
-
分析、フィルタリング、追跡が簡単になった
-
後続のプロセスはいつでも拡張可能で、システムを再構築する必要がない
最小限のデモでさえ、「チケット収集の混乱」という長期的な課題を解決しました。
私たちはDifyの対話入口を社内ポータルに埋め込み、メールで全員に通知しました：
今後はITの問題を「ロボットに尋ねて」、ロボットが情報を整理してチケットを作成し、ITが引き継いで処理します。
5.1 もう一歩先を見ると：この試みがAI駆動開発の可能性を示している
全体のフローが実際に動いた後、私ははっきりと感じました：
「AIが理解し、プラットフォームが保持する」この組み合わせは、私たちが内部ツールを構築する方法をすでに変えている。
過去に小さなシステム（例：チケット、資産管理、サービスフィードバック）を作成するには、
ITを巻き込み、スケジュールを組み、表構造を作り、ページを作り、APIを接続……プロセスは完全だが時間がかかる。
今回Dify + HAPを使った体験は全く異なりました：
-
アイデアが形になる速度が以前よりずっと速い
-
多くのロジックを自分で書く必要がなく、AIがまず代わりに立つ
-
ツール間の連携も軽量になった
-
大部分の時間を「業務を定義する」ことに費やすことができる
つまり：
AIは開発を代替するのではなく、より多くの人を「自分で何かを構築できる」状態に導く。
これは、私がこのプロジェクト全体で最も予想外だった部分です。
第六章：最後に——チケットは始まりにすぎない
システムが動くようになると、まずはしばらく安定して運用しました。
その間に私は2つのことを追加し、この体系を少し補完しました。
6.1 チャットロボットを「本当に問題を解決できる人」のように——知識ベースを追加
チケットフローが安定した後、Difyに基礎的な知識ベースを構築しました。
内容は非常にシンプル：
-
よくあるネットワーク問題
-
メール同期問題
-
VPN使用ガイド
-
パソコンが起動しない/ネットに接続できない場合の基本チェック方法
-
よく繰り返されるアカウント関連の手順
この取り組みの効果は非常に明確でした：
本当にチケットを作成する必要のない小さな問題に対して、ロボットが直接解決できる。
ユーザーが質問した後、多くの場合チケットを作成する必要がなくなり、ITの負担も大幅に軽減されました。
チケット入口の「知的レベル」は、質問するだけではなく、知識の蓄積によって高められるのです。
6.2 HAPの部分では、すでに「チケット保持」から「チケットシステム」へとアップグレードを始めている
この記事では、最小限の可用性を持つ闭环を主に説明しました：
チャット → 情報収集 → チケットをデータベースに落とす
しかし、この基础上でさらに進むと、非常にスムーズです：
-
チケット処理フローの作成
-
権限、ビューの追加
-
SLAの設定
-
部門別統計ダッシュボードの作成
-
処理者用ワークスペースの作成
-
跨チーム協力ノードの作成
これらは空想ではなく、HAPの能力がすでにサポートしているものです。
私たちのチーム内では、すでに「完全なチケットシステム」の方向に構築を始めています。単なるデータコンテナとして使うのではなく。
しかし——
この部分の内容は大きすぎて、この記事に詰め込むのは適切ではありません。
もし興味がある、続きを見たいという方がいれば、ぜひいいねやコメントで教えてください——
後で2つの記事を別に開いて、以下を詳しく説明します：
-
知識ベースを基に、Dify Chatflowを「フィールド収集」から「本当に問題を解決する」ものへとアップグレードする方法
-
HAPを基に、完全なチケットシステム（処理フロー、SLA、協力、ダッシュボード、レポート）を構築する方法