AIネイティブ経営の実践事例：Kiriromは契約・経理・開発をどこまでAIで回しているか

Kirirom（キリロム）では、契約・経理・開発にAIを入れています。ただし、これは三業務をすべて自動化する取り組みではありません。契約はレビュー支援、経理は人とAIの分業、開発は検証と引き継ぎを含む日常運用まで進んでいます。

この記事は、完成した成功事例の紹介ではありません。2026年9月21日までに残った運用記録をもとに、実際に動いている範囲と未完成な部分を分けて記録します。公開できる条件で測定した削減時間や投資対効果は、まだありません。

契約：レビューは動いたが、「止めすぎるAI」という問題が残った

契約で最初に行ったのは、締結の自動化ではありません。届いた原文を残し、過去の合意や関連契約と突き合わせ、経営者が確認すべき箇所を特定することでした。

実例があります。2026年9月、あるコンテンツの権利譲渡契約を確認した際、AIは原文と過去の記録を照合し、口頭の合意と条文のずれ、権利範囲、支払条件、第三者素材の扱いを整理しました。その過程で、当事者間の契約だけでは解消できず、別の契約当事者による同意が締結前に必要だと分かりました。この案件は、確認が終わるまで未締結のまま止めています。

ここでAIがしたのは「締結してよい」という判断ではありません。

• 契約書のどの文言が、既存の合意や資料と異なるかを示す
• 期限、権利、対価、再利用条件など、確認対象を原文へひも付ける
• 別の契約との衝突を見つけ、締結前に必要な確認を出す
• 未確認の素材や条件を、確認済みのように扱わず残す

一方、法務判断と締結は人が担います。条件を受け入れるか、どのリスクを許容するか、相手方へ何を返すか、弁護士など専門家へ相談するかを決めるのも人です。

実運用で分かった限界

AIへ法務レビューを任せた別の業務では、厳密に守る必要がない箇所まで警告し、わずかなリスクを避けるために運用コストを増やす問題が起きました。保険料率や税、制度区分などの数値も、AIの回答をそのまま対外説明へ使える状態ではありませんでした。

この失敗から、「違反の可能性を見つける役割」と「事業上どこまで許容するかを決める役割」を分ける必要があると判断しました。ただし、許容ラインをどこに定義し、誰が更新するかは未完成です。

現在、契約で止める条件は明確です。

• 原文や関連契約を確認できない
• 既存契約との衝突を解消できない
• AIが示した法令・料率・期限を一次資料で確認できない
• 事業上の許容リスクを人が決めていない
• 相手方への回答、条件変更、署名へ進もうとしている

つまり契約では、AIの価値は「正解を代わりに決めること」ではなく、判断前に見落とせない論点を原文へ戻せることにあります。レビュー件数、所要時間、見落とし率は未計測です。

経理：定型処理は進んだが、最後の確認を人から外していない

経理は、三業務の中で「AIが実際の業務システムへ触れる範囲」が最も見えやすい領域です。2026年9月21日時点で、専任のAI経理社員が、記帳から支払いや申告まで自律的に完了しているわけではありません。Webやメールからの請求書取得、銀行明細との照合、仕訳候補の作成、証憑の関連付け、支払一覧の更新、入金消込などを、業務ごとに試しています。

例えば公共料金では、AIが対象月の請求書を取得し、契約の増減と金額を確認して、支払一覧へ反映します。銀行の引落処理では、同期された明細を原本と照合し、重複の可能性を確認してから登録候補を作ります。給与や住民税では、前月の処理を参照しながら仕訳を準備します。

ただし、入口と出口には人がいます。

• ログインとパスワード入力は人が行う
• 会計データへ登録する前に一覧を人が確認する
• 金額や件数が普段と違えば、自動で確定せず「要確認」で止める
• 振込と税の納付は人が実行する
• 消費税など判断が分かれる処理は専門家へ確認する
• 領収書などを取引先へ送る前に、人が内容と送信先を確認する

この境界は、単に自動化が遅れているから残っているわけではありません。認証情報をAIへ渡さない、送金責任を人に残す、二重計上を最後に防ぐ、社外連絡を勝手に送らない、といった理由で意図的に残しています。

「自動化できたか」より、「その月に本当に使えたか」を見る

経理では、手順を作っても、そのまま毎月の実運用になるとは限りませんでした。

• 事業者が請求書PDFを提供しておらず、画面確認しかできない
• 紙の請求書は撮影と取り込みを人に頼る
• 銀行が会計ソフトと連携されておらず、通帳画像から確認する
• Web上の請求が確定する前はページを取得できない
• 同じ金額の契約があり、金額だけでは取引を特定できない
• 自動登録の設定が月によって異なり、二重計上の危険がある

こうした例外は、「経理をAI化する」という一つの大きな計画ではなく、実際の請求や引落が来た時点で一つずつ見つかりました。できなかった箇所を人が引き取り、次回に同じ迷いが起きないよう確認条件を更新しています。

担当者からは作業負担が減ったという実感が得られています。しかし、作業時間を同じ条件で計測した記録はありません。したがって、削減率や投資対効果はこの記事では成果として掲げません。現時点で確認できる成果は、複数の定型処理でAIが下準備と登録候補まで担い、人が確認すべき箇所が言語化されたことです。

開発：「AIに作らせる」から、「人が決める場所だけで止める」へ変わった

開発では、AIがコードを書くことよりも、経営者へ何を聞き、どこから先を自分で進めるかが問題になりました。

初期の運用では、質問フォーム、要件定義、機能レポートを分けて提示していました。実際に使うと、質問だけを見ても理由が分からず、資料を行き来しなければ判断できませんでした。「見にくい」という指摘を受け、機能の説明と、その場で決める質問を一つの画面へまとめる設計に変えました。

現在は、AIが会社と案件の文脈を読み、機能候補を洗い出し、次の三つに分けます。

• 会社の基準から明確に決まることは、理由を残して進める
• 前提に依存する推奨は、その前提を明記して仮決定する
• 後から直すコストが高い経営判断だけは、人へ返す

人が止まるのは、主に目的と重要仕様を確定する場面です。認証方式やデータの持ち方といった技術的な質問を、そのまま経営者へ投げないようにしました。

運用を変えた三つの失敗

一つ目は、機能の依存関係を見落としたことです。不要に見えた機能を外した後で、別の機能も外すと必要な要求を満たせないことが分かりました。以後は、機能を削る前に、どの要求を支えているかを確認します。

二つ目は、質問と判断理由を別々に見せたことです。判断する人の負担を、質問数だけでなく「資料を行き来する回数」として捉え直しました。

三つ目は、外部サービスの条件を推測で置きかけたことです。一次情報を確認すると前提が異なり、設計そのものを戻しました。費用、利用制限、外部サービスの仕様を確認できなければ、実装へ進めない扱いにしました。

実装後は、決めた要件を満たすかを機械検査と画面確認で確かめます。検査が失敗した場合、合格条件を弱めて通すことはしません。外部公開、費用発生、データ削除など後戻りしにくい操作は、人の承認が得られるまで止めます。

この運用は、この記事で扱う三業務の中では最も定着しています。ただし、要件定義の方式と現在の作業台帳の接続など、統一し切れていない部分もあります。開発時間、手戻り率、障害件数の導入前後比較は未計測です。

三つの現場から変わった判断

契約、経理、開発を並べると、共通しているのは手順ではなく、進め方に対する判断です。

以前は「AIがどこまで代行できるか」を広げようとしていました。現在は、次の順で考えています。

1. どの原文と現在の基準を見れば、AIが準備できるか
2. 間違えたときの影響が大きく、人が決めるべき箇所はどこか
3. どの条件ならAIを止め、原文・専門家・責任者へ戻すか
4. 実行後に、正しかったことを何で確認するか

この順序に変えると、自動化率の高さは主目標ではなくなります。経理で振込を人に残すことも、契約を未締結で止めることも、開発で公開承認を待つことも、失敗ではありません。人が判断する範囲とAIを止める条件を先に決めた結果です。

この事例からは、まだ言えないこと

この記事の根拠は、Kirirom社内の運用記録、役割定義、検証記録です。三業務を完全自動化した証拠ではありません。顧客企業へ同じ方法を適用した比較試験でもないため、次のことは断定できません。

• 他社でも同じ分担が最適である
• AI導入によって一定割合の工数やコストを削減できる
• 契約・会計・開発の専門判断をAIが代替できる
• 三業務が完全に自律運転している

確かめられたのは、業務ごとに「AIが準備する範囲」「人が決める範囲」「止める条件」を分けると、AIを実務へ入れた後の失敗を具体的に直せることです。

自社の現在地を全体から確認する場合は、AIネイティブ経営の4段階を参照してください。対象業務の選定と最初の運用設計を集中して進めたい場合は、AIネイティブ経営合宿で扱う内容を確認できます。