この記事では AI HACK 2026 に向けて制作した 「Aida（あいだ）」 を紹介します！

離婚した父母が、別々に暮らしながらも、子どもを一緒に育てていくための適切なコミュニケーションを支援するためのアプリです。

どんなアプリなの？

先に、使う人から見て何が起きるかを書きます。

離婚した父母が、同じアプリに入っているのに、一度も互いの言葉を読まないまま、
連絡事項の共有や面会交流の取り決め、臨時出費などの調整を済ませる、というアプリになります。

画面は4つだけ

タブ	何をするところか
ホーム	いま何が起きているか。決まったこと、待っていること
相談	AIと1対1で話す。書いた言葉そのままでは届きません。整えて伝わります
取り決め	当事者が自分で書く離婚協議書・公正証書のベース。養育費・面会交流など8つの論点。 AIは、この欄に触れません
決まったこと	お話し合いで決まったことの控え

このアプリのポイント

AIを、対話の相手ではなく「あいだ」に置いたことです。

一般的なチャットAIは、ユーザーと1対1で向き合います。Aida は2人のあいだに立ちます。

区分	コミュニケーションアプローチ
一般的なAIチャット	人 ⇄ AI（AIは相談相手）
Aida	人 ⇄ AI ⇄ 人（AIは、書き直して届ける通訳）

背景：離婚しても、コミュニケーションは続く

さて、なぜこのアプリを作ろうと思ったのか？そのきっかけを詳しくお伝えしておきたいと思います。

まず前提なのですが、私は離婚当事者ではありません。知り合いの弁護士とたまたま「AIによる業務効率化」について雑談していた際、話題にあがったトピックが発端でした。

その弁護士は離婚周りの仕事を行った後も、元夫婦間のコミュニケーションをフォローすることがあり、そこの対応が想像以上に元夫婦間にとっての負荷だけでなく、面会の拒絶や臨時出費の適切な対応ができずに子どもの健やかな成長を妨げる要因になっていました。

また今回のアプリを作るにあたって、当事者の方に実際の夫婦間でのやり取りのトピックを教えていただく機会もありました。AIに今までのやりとりを整理・要約してもらったものですが1年半で約1,000件にのぼるものでした。

種類	相談トピック・概要
送迎	習い事、実家との受け渡し、「XX時には連れて行けない」などの相談・調整
学校	行事の日程の共有、三者面談の分担、提出書類、持ち物
お金	塾・家庭教師・メガネなど。1万円を超えたら折半という取り決めの運用
進路	転校の手続き、塾選び、進学・進路の方針のすり合わせ
健康	発熱、通院の調整、発達特性についての共有
生活	お小遣いの方針、ゲームの時間、しつけのすり合わせ

体感で8割以上が、事務連絡でした。

子育ては、離婚では終わりません。むしろ毎日続きます。
そしてその実務は、二人でしか回せません。

しかし、その中で感情的な対立が原因で合意や意思決定を阻害してしまうケースが多くありました。

続かなくなるのは、事務連絡

感情的な対立は、全体で見れば数十件でした。割合としては、ごく一部です。

ただ、いったん発火すると、様子が変わります。
送迎の相談から始まって、法的な語彙が持ち出され、何年も前の金銭の話まで戻っていく。
子どもの話は、どこかへ行ってしまいます。

ここで 問題になるのは、その数十件が、残りの1,000件の円滑なコミュニケーションを止める要因になることです。

一度そうなると、「送迎お願いできますか」の一行を送るのに、身構えるようになります。
返事の一言が、どう解釈されるか分からない。だから送らない。だから決まらない。

決裂しているのではありません。事務連絡が、続かなくなり、それによって子どもの健やかな成長の妨げになってしまうのです。

Aida が目指していること

父母のあいだの感情的な対立を AI が和らげ、円滑な子育てにつなげる。

発端は、**「いま人がやっていることを、AIに担ってもらえないか」**でした。

離婚の実務では、あいだに人が入っています。

誰が	何をしているか
弁護士	双方の言い分を個別に聞き、角の立つところを落として相手方に伝える。実際、面会の日程調整を弁護士同士が代理しているケースがあります
仲介事業者	当事者のあいだに立ち、文面を仲介する
行政書士・公証人	決まったことを書面にする

この人たちがやっている一つの側面は、感情の緩衝材になることです。
言い分を否定するのではなく、受け取ったうえで、伝わる形に置き換えて渡している。必要に応じて離婚協議書や公正証書という形に合意を落とし込んでいる。

そしてそれは、効きます。 裁判所や代理人が入れば、養育費の取り決め率は
43.6% → 81.2% に上がります。

なぜ、その役割をAIに任せたいのか？

人手では、届く範囲に限りがあるからです。

カテゴリ	課題
費用	双方が弁護士を立てれば 60〜100万円仲介サービス弁護士よりも単価は低いが都度お願いするのはコスト的に厳しい
時間	深夜の発熱の連絡に、24時間は対応できない
頻度	共同養育の連絡は毎日です。その都度、人を挟めない

日本の離婚の 87.5% は協議離婚で、誰も入ってきません。
取り決めをしない理由の 第1位が「相手と関わりたくない」 なのに、
「関わらなくて済むようにする人」が、そこにはいない。

人がやると成立しない条件——非同期・24時間・低単価——で、
同じ役割を果たせるか。それがこのプロダクトの問いです。

そのために実際にやっているのは、伝えることです。

父はAIと話し、母もAIと話します。
AIが、責める言い回しや感情の部分を取り除いて、決めるために要る事実・背景だけを相手に伝えます。

入力（父が書いたもの）
  月3万が限界。こっちだって仕事切られて必死なんだよ。
  そっちだって働いてるだろ、少しは考えろ

母の画面に届くもの
  養育費について、月額3万円までを希望されているそうです。
  背景として、現在は職を失っているとのことです。
  ── お相手が書いた言葉そのものは含まれていません。

大事なのは、「必死なんだよ」が届かなかったことではありません。

月3万円という希望と、仕事を失ったという事情が、相手に届いたことです。

このままの言葉では、送れなかったはずです。送れば、話し合いはそこで止まります。
だから多くの人は送らない。そして何も決まらない。

Aida がやるのは、送れなかったものを、送れる形にして届けることです。
「直接メッセージを転送しない」は、そのための手段にすぎません。

数字でも同じことが起きている

ちなみに国の調査（全国ひとり親世帯等調査）では、**養育費の取り決めをしない理由の第1位が「相手と関わりたくない」**です。

そして、離婚方法別に見ると差は明確です。

離婚方法	養育費の取り決め率	面会交流の取り決め率
協議離婚（母子世帯 758,312）	43.6%	27.9%
その他の離婚（同 192,146）	81.2%	56.5%

裁判所や代理人という第三者が入ると、取り決め率はおよそ2倍になります。
そして件数が最も多く、第三者が最も入らないのが協議離婚です。ここに第三者を投入するのが最も効きます。

さらに、改正民法（令和6年法律第33号）が2026年4月1日に施行され、父母には子の利益のために協力する責務が明確化されました。
法は「協力せよ」と定めましたが、協力の手段は用意していません。

離婚協議書・公正証書作り：目的と道具の扱いの違い

ちなみに、離婚にあたって離婚協議書ないし公正証書を作ることがありますが、機能面としてはサポートしつつも、目的とはしていません。


目的	離婚しても、子どもが健やかに育つための基盤になる（金銭的な部分含めて生活基盤が守られる、親に子どもが会えること）
手段	親同士が直接やりとりせずに、決めて・運用できるようにすること
道具	取り決めの記録、公正証書のドラフト

そこで用が済むなら、それは書面作成サービスです。
けれど実際には、そのあとに何年も、送迎と学校と費用の連絡が続きます。

決める段階と、そのあとの日々を、ひとつの道具で貫く。

先行サービスは、ここが分断されていました。
離婚協議書・公正証書などをベースにした計画書を「作る」ものと、メッセージを「やりとりする」ものが、別々にあります。

前置きが色々と長くなりましたが、ここからAI によるコミュニケーションの仲介のためにメッセージを直接転送せず、でも目的や背景をどのように抽出して相手に届けるのか？その仕組とポイントを解説していきます。

全体のフロー

ケース開始 — メールアドレスだけ。お名前も、ご関係の状態もうかがいません
招待 — 招待リンクを作り、ご自身の手で相手に渡します（アプリは相手に接触しません）
個別対話 — 各当事者がAIと1対1で話します。感情は受け止めますが、越えません
論点の抽出 — 対話から「合意すべき項目（養育費・面会交流など）」を分類します
提案の構造化 — 金額や日付を、原文の表記のまま取り出します
取次ぎ — 提案＋事情だけを、検査を通したうえで相手に渡します
取り決め — **当事者自身が書いて残します。**渡すかどうかも自分で決めます
合意 → 文書化 — 記録が一致したら、公正証書のドラフトを生成します

技術構成

Google Cloud をベースに、AI HACK のスポンサーである「OrcaRouter」を利用しながら、AI のAPI 処理周り含めて開発しました。

要素	技術
フロントエンド／API	Next.js 16 / TypeScript / Tailwind CSS 4
LLM ゲートウェイ	OrcaRouter（唯一の入口）
モデル	SMALL `gpt-4.1-nano` ／ MEDIUM `gpt-4.1-mini` ／ LARGE `gpt-5.1`
データ	Firestore
実行環境	Cloud Run（asia-northeast1）
認証	Firebase メールリンク認証 → HMAC-SHA256 署名付きセッション

OrcaRouter とは

複数のLLMプロバイダを、1つのエンドポイントから呼べるようにするAIゲートウェイです。本ハッカソンのスポンサーで、今回のLLM呼び出しはすべてここを通しています。

OpenAI互換のAPIなので、既存のコードはエンドポイントとキーを差し替えるだけで動きますし、モデルは openai/gpt-4.1-nano のようにプロバイダ名込みで指定し、環境変数を書き換えるだけでモデルを入れ替えられます。

もうひとつ特徴的なのが、単価を API で公開していることです（/api/pricing）。単価表をアプリに持たずに済むので、呼び出しごとの原価を、そのときの単価で記録できます。

Aida の概要：転送せずに、伝える

Aida の構造はこうです。

点線は、実装されていない経路です。
「送らないようにしている」のではなく、書ける場所がありません。

父はAIと話し、母もAIと話します。
書いた言葉そのものは越えず、合意に必要な事実だけが、伝聞のかたちで越えます。（挙動は冒頭のとおり）

図で見ると引き算に見えますが、やっていることは足し算です。
このままでは送られなかったはずのものが、相手に届いています。

1ターンで、何が起きるか

具体的にどのようなプロセスでAIとの会話シーケンスを進めているのか？ **「書いてから、相手に届くまで」**を1枚にします。

青い枠が「本人しか読まない領域」、橙の枠が「越える領域」です。
この2つが混ざらないことを、以降のすべての仕掛けで守っています。

なぜ「相談トピック」を選ばせるのか

自由入力なのに、書き始める前にトピックを1つ選んでもらいます。
一見すると手間を増やしているだけですが、ここが構造化の起点です。

トピックは5つの分類・29件あります。

分類	例
お金のこと	塾・習い事の費用／進学費用の分担／今月の支払いを待ってほしい／医療費
子どもと会うこと	今回の日程を変更したい／学校行事に参加したい／長期休暇の過ごし方
学校のこと	提出書類のことを伝える／面談の分担／持ち物・購入するもの
育ちのこと	進学について／医療について／転居・転校について
日々の連絡	送迎をお願いしたい／子どもの体調を伝える／忘れ物の受け渡し

**実データの分類から起こしました。**当初は交渉を中心に14件ほど並べていましたが、
実際の8割は事務連絡だったので、重心をそちらへ移しました。

選ばせているのは、3つのものが同時に決まるからです。

決まるもの	効き先
書き出しの案内と例	人に。空の入力欄に向かわせない
紐づく論点（`linkedTopic`）	相手に。「養育費について、…」という見出しが決まる
種別（`kind`）	仕組みに。控えを残すか、取り決めに触れてよいか

たとえば「今月の支払いを待ってほしい」を選ぶと、画面にこう出ます。

今月のお支払いのことですね。
いつまでなら都合がつきそうかを書いていただけます。
事情は、書かなくてかまいません。

書き出しの例
  今月は、来月末までお待ちいただけませんか
  分けてお支払いできないでしょうか

「事情は、書かなくてかまいません」と書いてあるのが要点です。

書く人は、何をどこまで書けばいいか分からないまま入力欄に向かいます。
そこで言い訳を長々と書いてしまうと、それは取次ぎで落ちます（越えないので）。
先に「要るのはこれだけ」と示しておくほうが、双方にとって早い。

トピックは、分類のためではなく、「何を書けばいいか」を渡すためにあります。

もちろん、選ばずに書き始めることもできます。
選ばなかった場合は、柔軟な型で取り出し、見出しは付けません。
選ばせることを、必須にはしていません。

最大の壁：「転送しない」を、どうやって保証するか

「メッセージを直接転送しません。内容を整理してお伝えします」は、言うだけなら簡単です。
問題は、それを信じてもらえる形で保証できるかでした。

このプロダクトの利用者は、相手の感情的な言葉を読みたくない人です。
一度でも原文が漏れたら、そのユーザーはもう戻ってきません。「たぶん大丈夫」では使えません。

失敗ルート：プロンプトで頑張る

最初に考えたのは、当然ながら「システムプロンプトで、原文を出さないよう強く指示する」でした。

これはすぐに捨てました。

LLM の出力は毎回変わります。プロンプトは確率を下げるだけで、ゼロにはしません
そもそも、原文がコンテキストに入っている限り、出力に混ざる可能性は消えません
そして何より、利用者に「プロンプトで気をつけています」と説明しても、信じる理由がありません

「気をつける」を、「書けない」に変える必要がありました。

まず、置き場所で分ける

仕掛けの前に、データの置き場所です。

相談は、当事者ごとに別のドキュメントです（IDに partyId が入ります）。
同じスレッドでも、父と母で物理的に分かれています。

「見せない」のではなく、「同じ場所に無い」。

これが土台です。そのうえで、越える1本の経路をどう作るか。ここからが本題です。

打ち手は4つあり、効いた順に並べます。

解決策1：AI に自由に文章を書かせない。枠を埋めさせる

いちばん効いたのは、これです。

トピックごとに「何を取り出すか」を型で決めておき、
LLM には、原文からその枠を埋めることだけをさせます。

そして重要なのは、型が2種類あることです。埋める人が違います。

	誰が埋めるか	型の性格
相談からの抽出	LLM	全部 `string`。「原文にある表記をそのまま」
取り決めの入力	人（画面のフォーム）	`integer` と `enum` で厳密

LLM に渡している型は、これだけです。

数値型がありません。「15万」は 150000 ではなく、"15万" のまま受け取ります。

LLM に、解釈をさせません。取り出させるだけです。
単位の換算も、年の補完も、決定的なコードでやります。
「15万」「15万円」「150,000」を円に直すのは、LLM ではなく parseYen() という関数の仕事です。

一方、人が埋める型は論点ごとに用意してあり、厳密です。

論点	項目
養育費	`monthlyAmount`（整数）／`payDay`（月末・5日・10日・25日）／ `until`（18歳・20歳・22歳の3月・卒業）／`payeeAccount`
面会交流	`frequency`（月1・月2・週1・その他）／`dayOfWeek`／`weekOfMonth`／ `timeRange`（`10:00-17:00` の形）
財産分与	`method`（一括・清算済・後日）／`payerSide`／`amountYen`／`dueDate`

多くが enum です。「毎月末日に」も「月末に」も「ラスト」も、画面で選べば LAST_DAY です。
そしてこの型は、公正証書の条項ひな形と1対1。合意した値をそのまま流し込めば条項になります。

厳密な型は、人に埋めさせる。曖昧なままの型を、LLM に渡す。
逆にすると、モデルが「たぶん月額だろう」と判断して埋めてしまいます。

そして、相手に届く文章は、こちらが組み立てます。

LLM は「書く」のではなく「取り出す」。
自由に文章を書かせる経路が無いので、そこから原文が滲むことがありません。

解決策2：テストではなく、実行時の門にする

型を定義しても、まだ足りません。

AIが生成した「事情の要約」の中に、原文の言い回しが混ざる可能性が残るからです。
これはコンテキストの問題ではなく、出力の問題です。そして LLM の出力は毎回変わります。

テストで確かめるだけでは足りません。本番の1回1回を検査する必要があります。

そこで、越境の直前に実行時の検査を置きました。3つ通らないと越えません。

3つとも、意味を判定していません。文字列で判定しています。

検査	何を見るか
① 逐語引用	原文と越境文を突き合わせ、N文字以上の連続一致（現在 N=10）
② ホワイトリスト	抽出時に付けたカテゴリが、許可した4つに入っているか
③ 伝聞形	文ごとに末尾を見る（「〜とのことです」で終わるか）

「言い換えているか」を意味で判定するのは不可能ですが、
「そのまま写していないか」は文字列で判定できます。

①逐語引用の検出が、C1 を機械的に確かめる唯一の方法です。

②ホワイトリストは、ブラックリストにしませんでした。

export const CONTEXT_CATEGORIES = [
  "INCOME_EMPLOYMENT",  // 収入・就業状況の変化
  "CHILD_STATUS",       // 子の状況（進学・病気・生活）
  "SCHEDULE_CONSTRAINT",// 日程・場所などの制約
  "HEALTH_LIVING",      // 健康・生活状況
] as const;

ブラックリスト方式では必ず漏れます。 ここに無いものは、たとえ無害に見えても越えません。

③伝聞形式は、精度ではなく責任の問題です。
AIには真偽の検証手段がありません。「失職した」と断定すると、虚偽の申告をAIが保証したことになります。
だから「失職したとのことです」しか許していません。文ごとに末尾を検査しています。

落ちたとき、何を選ぶか

検査に落ちたときの挙動が、このプロダクトの性格を決めました。上の図の右下です。

再生成は1回だけです。繰り返しません。待たせるうえ、通る保証がないからです。

そして2回目も落ちたら、事情（context）を捨てて、提案（payload）だけを越えさせます。

事情が伝わらないことより、原文が越えることのほうが重い
ただし取次ぎ自体を消すと、相手は何も知らないままになるので、提案は必ず越えます

「安全側に倒す」と一言で言っても、何を捨てて何を残すかは設計判断です。ここは明示的に決めました。

解決策3：対になる、2つの検査

ここが、後から一番効いた設計です。

越えるものは2つあります。文章（content）と、構造化された値（payload）です。
この2つに、正反対の検査をかけています。

越えるもの	検査
`content`（相手が読む文章）	原文と逐語一致してはならない
`payload`（金額・日付などの値）	原文に逐語で書かれていなければならない

同じ「逐語一致」という道具を、片方では禁止に、もう片方では必須に使っています。

一文にすると、こうなります。

言葉は渡さない。事実は、原文のまま。

なぜ対にする必要があったのか。実データに通して、分かったからです。

締切の前日、冒頭に挙げた約1,000件のやり取りを、そのまま実装に通しました。
結果、取次ぎの検査は全部すり抜けたのに、値の取り出しは3つとも落ちていました。
「15万」を 15 と解釈する。スキーマの説明文をそのまま値として返す。
そして——「月末までに」としか書いていない入力から、2026-03-31 という日付が出てくる。

文章側の検査では、これは止まりません。言い換えられているので、逐語一致しないからです。

逐語一致を「悪」とだけ扱っていたら、この穴は塞げませんでした。

LLMコスト：単価表だけを見て選ぶとコスト増

審査項目に「LLMコスト」が独立で立っていたので、ここは実測にこだわりました。

階層設計

OrcaRouter を唯一のゲートウェイにし、その手前に自前の LlmRouter を置いて、
用途を3階層（SMALL / MEDIUM / LARGE）に振り分けています。

階層	モデル	用途	頻度
SMALL	`gpt-4.1-nano`	意図分類／提案の構造化	最高（全メッセージ）
MEDIUM	`gpt-4.1-mini`	感情の受け止め／事情の抽出	中
LARGE	`gpt-5.1`（`reasoning_effort=medium`）	現状、出番がありません（下記）	—

頻度と単価が逆相関します。 往復が増えても、原価はほぼ SMALL / MEDIUM で決まります。

結果として、LARGE を使わなくなりました

当初 LARGE は「調停案の説明文」を書かせるために用意していましたがやめました。

**危険の検知も、LLM を使っていません。**決定的な判定でフラグを立て、人が読みます。
「AIは判定しない」——誤検知の帰結が取り消せない（通告から家庭に調査が入りうる）ためです。

Router の外から SDK・エンドポイント・APIキーを参照していないことを、静的検査しています。
入口が1つでないと、原価も、モデルの差し替えも、後から効かなくなります。

実測してわかった、推論モデルの罠

SMALL の既定を gpt-5-nano にしていました。入力単価が $0.05/1M で、gpt-4.1-nano の $0.10/1M の半額だったからです。

でも、同じタスクを実測したら、こうなりました。

モデル	入力単価	出力トークン	円/回
`gpt-5-nano`（既定）	$0.05	1,358	0.0822
`gpt-4.1-nano`（非推論）	$0.10	29	0.0032

入力単価が半分のモデルが、25倍高くつきました。

原因は思考トークンが出力に計上されることです。分類タスクなので、答えは29トークンで足ります。
残りの1,300トークンは、「これは養育費の話か日程の話か」を考えるために燃やされていました。

そこで規約を2つ立てました。

M-1: 高頻度の処理には非推論モデルを使う。 分類・抽出に思考は要りません
M-3: 階層を変更したら、採用前に実測する。 単価表だけで判断しない

最後に

このプロダクトの直接の利用者は父母ですが、本来の受益者は子どもです。

養育費が決まらないのは、お金がないからだけではありません。話したくないからです。
面会交流が続かないのは、会いたくないからだけではありません。連絡したくないからです。

直接やりとりしなくても決められるなら、決められます。

改正民法は「子の利益のために協力せよ」と定めました。
その協力の手段を、直接やりとりしなくても成立する形で用意できないか、というのが Aida の答えです。

転送しないことが達成ではありません。達成は、伝わったことのほうです。
このままでは送られなかったはずのものが、相手の画面に届いている。
それを、たまたまではなく毎回そうなる形で作れたところまでが、9日間の結果です。

9日間、ありがとうございました。AI HACK 2026 の主催・スポンサーの皆さま、そしてヒアリングにご協力いただいたお二人に感謝します。