プロジェクトへ戻る
フォーム作成 → 依頼 → AIの追加質問 → 納品 → 承認

AI HACK 2026 · 公開中

Relay

デザイン制作の依頼を受付から追加確認、納品、承認まで一か所で追えるAIエージェントです。

東京のAIハッカソン「AI HACK 2026」（テーマ：業務を自立化するAIエージェント）で、デザイナーと2人で作った制作依頼管理サービスです。私は開発をすべて担当し、AIの出力を原文の引用と照合してから保存するGoワーカーと、AIが止まっても業務が止まらない依頼フローを実装しました。

結果公開サービス · 公開リポジトリ · 97コミット · AI出力の根拠検証

期間
2026.09
担当範囲
開発全体 · Go API · Riverワーカー · AI連携 · React
チーム
2人チーム（開発1・企画/デザイン1）
リポジトリ
公開リポジトリ

リンク

公開サイトGitHubZenn記事AI HACK 2026

制作の前後にある管理業務を、AIに引き受けさせる

チームメンバーのデザイナーは、複数のマーケターから依頼を受けるたびに、目的・掲載先・素材の確認、優先順位、進捗共有、納品連絡を一人で抱えていました。AI HACK 2026のテーマ『業務を自立化するAIエージェント』に合わせ、この管理業務を任せられるサービスを作りました。

2025年の韓日未来世代フォーラムで、私は『韓日協力をスローガンで終わらせず、若者がハッカソンや共同プロジェクトで実際に経験すべきだ』と発表しました。Relayは、その提案を自分で実行したプロジェクトです。日本のハッカソンに出場し、日本の制作現場の課題を日本語のプロダクトとして形にしました。受賞には至りませんでしたが、公開できる形まで完成させました。

依頼が処理される流れ

AIの結果は、検証を通ったものだけが業務に届く

  1. 01

    依頼フォーム

    React · 依頼者と担当者の画面

  2. 02

    Go API

    認証・権限・依頼の状態

  3. 03

    ジョブ保存

    PostgreSQL + River

  4. 04

    AI呼び出し

    OrcaRouter · 上限付き

  5. 05

    根拠検証

    引用照合・世代比較

AIの要約は、原文に引用がある文だけを保存する

依頼内容の要約は、担当者が原文を読み返さずに判断する材料になります。AIが原文にない期限や条件を書けば、要約があることでかえって誤った作業が始まります。

要約を言い換えではなく抽出にしました。各項目に根拠の種類・ID・引用文を持たせ、Goで引用が実際の依頼本文・回答・コメントに含まれ、本文と一致する場合だけ保存します。

要約の検証関数と週次レポートの検証関数を単体テストで確認しました。根拠のない出力は保存されず、記録から集計したレポートへ戻ります。

制約・実装・学びを見る

プロンプトで『事実だけを書いて』と指示しても、出力が守る保証はありません。検証はモデルの外、サーバー側のコードで行う必要がありました。

  • JSON出力を指定し、質問は最大8件・要約は1〜6項目に制限です。
  • 引用元が存在し、空白を正規化した本文と一致するかを検証しました。
  • 未完了の依頼では納品情報を根拠にできないよう制限です。
  • 想定外のフィールドや余分なJSONを拒否しました。

LLMの出力は、APIの外部入力と同じく、信頼する前に検証する対象だと学びました。

依頼者が書いた本文が、AI要約の根拠になる

AIの処理状態と、業務の状態を分けた

AIの分析が終わっても、制作が終わったわけではありません。また、AIが処理している間に依頼者が内容を変えたり、担当者が作業を進めたりすることもあります。

AI処理をPostgreSQLに保存するRiverジョブにし、実行時の世代を記録しました。結果を反映する前に世代を比べ、依頼が変わっていれば結果を破棄して現在の状態を残します。完了はAIではなく人の承認でのみ記録します。

PostgreSQL統合テストで、提供元の呼び出し中に完了した依頼、重複・古いジョブ、手動で追加したタスクの保持を確認しました。

制約・実装・学びを見る

AIの応答には数十秒かかることがあり、ブラウザを閉じても処理は続く必要がありました。一方で、遅れて届いた結果が人の操作を上書きしてはいけません。

  • 依頼は送信時点で受け付け、AI分析はバックグラウンドで実行しました。
  • 世代比較で古い結果を破棄し、analysis_staleイベントを記録しました。
  • AIによる完了への変更をコード側で拒否しました。
  • 試行回数・出力トークン・実行時間に上限を設定です。

非同期処理では『いつ終わるか』より『終わったときに、まだその結果が正しいか』を先に考える必要があると学びました。

完了は、人の承認で決まる

AIが使えなくても、依頼と納品は止めない

ハッカソンのテーマは業務の自立化でしたが、APIキー未設定、利用上限、モデルの応答エラーは実際の業務で必ず起きます。

AIの出力はすべて『提案』として扱い、失敗時の代わりを用意しました。追加質問は一部だけ答えても進められ、納品文は編集可能な簡易文面に、週次要約は記録からの集計に戻ります。

キー暗号化・マスキング、CSRF、ワークスペース分離をテストで確認し、モックしたOrcaRouter応答を含む統合テストとDockerビルドを通しました。

制約・実装・学びを見る

AIの失敗をそのまま画面のエラーにすると、依頼者は依頼できず、担当者は納品できません。AIが役立つ場面と、人が最後まで進められる経路を両方残す必要がありました。

  • キー未設定時は管理者に設定リンク、依頼者に確認案内を表示しました。
  • APIキーを暗号化保存し、取得APIとAI入力からキーを除外です。
  • AI接続先を固定し、入力URLへキー付きで送らない構成しました。
  • ワークスペースと役割による権限をサーバー側で検証しました。

AIエージェントの信頼性は、AIが成功する確率より、失敗したときに人が次の行動を取れるかで決まると学びました。

APIキーは暗号化して保存し、取得APIでは返さない

サービスとGitHubリポジトリを公開しています。97コミットはすべて私のもので、Go単体テスト・PostgreSQL統合テスト・フロントエンドのビルド・Dockerビルドを通しています。

AIを使う機能では、まず『AIが間違えたら何が起きるか』『AIが止まったら誰が何をするか』を決めてから、プロンプトとモデルを選ぶようになりました。

未検証の範囲

受賞はしていません。実際のOrcaRouterモデルでの質問の質・費用・応答時間、メール到達、実務での時間短縮は、モックを使ったテスト以外ではまだ検証していません。

次に確かめること

  • 実際の依頼例で不足情報の見落としと不要な質問の数を測る
  • OrcaRouterでモデルごとの日本語の自然さ・JSON安定性・応答時間を比較する
  • 実環境でメール到達と重複防止を確認する