「規程や手順書を AI に読ませて、社員が質問したら答えてくれるようにしたい」。当社に来る生成 AI の相談でよく挙がるのが、社内文書検索です。仕組みの名前は RAG（社内文書を AI が検索し、見つけた文書をもとに回答する方式）。試作は速い。手元の文書を入れて質問すれば、答えらしきものはすぐ返ってきます。ところが本番に入れようとした途端に止まる。「役員会の議事録が一般社員の質問に出てきた」「去年廃止した旅費規程を根拠に答えた」「どの文書を見て答えたのか分からない」。3つとも、検索の精度ではなく、文書の扱いと運用が決まっていないことが原因です。
この記事は、社内文書検索をFDE（Forward Deployed Engineer）の方式で本番まで持っていくときに、FDE が発注側と一緒に決めることだけを扱います。順に、どの文書を入れてどれを入れないか（文書の棚卸し）、元の置き場の閲覧権限を検索にそのまま持ち込む方法（権限の写し）、回答に「どの文書のどこか」を必ず添える設計（根拠表示）、文書が変わったら索引も変わる運用（更新運用）、検索の当たり率と回答の正しさを分けて測る評価の5つ。Anthropic・OpenAI・Google・Microsoft の公式ドキュメントと、IPA（情報処理推進機構）の産業サイバーセキュリティセンターで公開されているガイドラインで確認できた事実を根拠にし、当社が経理 AX・kintone・案件管理システム刷新・Claude 導入で本番稼働まで伴走した経験を一般化して書いています。データを AI に渡す前の6項目（学習利用・保存場所・ログ・権限・分類・削除）は顧客データを外に出さずに AI を本番で使うに書いたので、そちらに譲ります。
社内文書検索を本番で使えるかどうかは、検索の精度より先に4つで決まる。①入れる文書と入れない文書を持ち主付きで決めたか（棚卸し）②元の置き場の閲覧権限が検索結果にそのまま効いているか（権限の写し）③回答に文書名と該当箇所が必ず付き、根拠が無ければ「分からない」と返すか（根拠表示）④文書の持ち主が更新したら索引も更新され、古い版が消えるか（更新運用）。評価は「探せたか」と「正しく答えたか」を分けて測り、テストセットは社員の実際の質問から作る。FDE は当社の標準である6週間でこの4つを発注側と決め、Echo 役に索引の持ち主を引き継ぐ。
この記事の要約
「検索できる」と「業務で使える」は別——試作が本番に乗らない3つの症状
社内文書検索の試作は早く形になります。AI ベンダーが提供する文書検索の機能を使えば、文書を入れて質問するところまでは短い手間で届く。IPA の産業サイバーセキュリティセンターで2024年7月に公開された「テキスト生成AIの導入・運用ガイドライン」（中核人材育成プログラムの受講生プロジェクトがまとめたもので、「独立行政法人情報処理推進機構および産業サイバーセキュリティセンターの意見を代表するものではなく、著者の見解に基づいています」と明記されています）にも、聞き取りをした組織の導入目的として「専門性の高いドキュメントの探索時間短縮」が挙がっており、社内文書検索が最初の用途になりやすいことが分かります。
同じガイドラインは、RAG を使う組織の課題として「回答精度に関するもの」が多く挙がったと書き、それを仕組みの課題と利用者の課題に分けています。仕組みの側は、RAG を使っても「ハルシネーションのリスクをなくすことはできない」こと。利用者の側は「ユーザがRAG活用に期待する効果と、現実的にRAGでできることの間にある認識のギャップが大きい」ことで、各組織はガイドラインや周知で埋めようとしているが「完全に埋めることは難しい状況にある」とあります。当社が現場で見る症状は、この2つが形になったものです。
| 症状 | 利用者に何が起きるか | 本当の原因 | この記事で扱う箇所 |
|---|---|---|---|
| 見てはいけない文書が出てくる | 一般社員の質問に、役員会の議事録や人事評価の資料が根拠として表示される | 文書の置き場では部署ごとに閲覧権限があったのに、検索用に集めた時点で権限が消えた | 権限の写し |
| 古い文書を根拠に答える | 廃止済みの規程や、改定前の手順書をもとに回答する。利用者は最新だと思って従う | 入れる文書を決めるときに版と持ち主を決めておらず、更新しても古い版が残る | 棚卸し・更新運用 |
| 何を見て答えたか分からない | 回答が正しいか確かめようがなく、結局元の文書を探し直す。使われなくなる | 回答に文書名と該当箇所を付ける設計を最初からしていない | 根拠表示 |
3つとも、検索の仕組みそのものではなく「文書の扱い」と「運用」の設計が抜けたときに起きます。PoC で止まる会社と FDE で動いた会社で書いた、PoC が本番に乗らない原因（判断者・データの持ち主・運用担当が決まっていない）と同じ構図です。社内文書検索の場合、データの持ち主とは「文書の持ち主」で、運用担当とは「索引を更新する人」です。この2人が決まらない試作は、答えが良く見えても本番に入れられません。
文書の棚卸し——入れる文書より「入れない文書」を先に決める
FDE が着任して最初にやるのは、文書の棚卸しです。FDE は初日に何をするのかで書いたデータ棚卸しを、文書に当てはめる。ただし社内文書検索では、順番が逆になります。入れる文書を集めるのではなく、入れない文書を先に決める。入れてしまった文書は検索で見つかってしまうからです。人事評価、役員会の議事録、取引先ごとの条件、個人の健康情報。これらが混ざった状態で試作を見せると、「便利だが怖い」という感想になり、本番の判断が止まります。
IPA のガイドラインは、RAG で回答精度を落とす情報として「ノイズが含まれる情報」「重複した情報」「最新版ではない古い情報」の3つを挙げています。裏返せば、棚卸しで決めるのは「何を入れるか」だけでなく、重複をどう潰し、版をどう1つにするかです。当社は棚卸しを次の表の6列で作ります。文書種別、置き場、持ち主、更新頻度、閲覧範囲、そして入れる・入れない・後回しの判定。
| 文書種別 | 置き場の例 | 持ち主 | 更新頻度 | 閲覧範囲 | 判定と理由 |
|---|---|---|---|---|---|
| 就業規則・各種規程 | 総務の共有フォルダ | 総務課長 | 年1〜2回 | 全社員 | 入れる。質問が最も多く、版が1つに決まっている |
| 業務手順書・マニュアル | 部署ごとの共有フォルダ、社内 Wiki | 各部署の主担当 | 月1回程度 | その部署 | 入れる。ただし部署ごとに閲覧範囲を分ける |
| 過去の問い合わせと回答 | メール、チャット、ヘルプデスクの記録 | 情シス・総務 | 毎日 | 全社員（個人情報を伏せた上で） | 後回し。個人名・案件名の伏せ方を決めてから |
| 会議の議事録 | 経営会議・部門会議のフォルダ | 各会議の事務局 | 毎週 | 出席者 | 入れない。閲覧範囲が会議ごとに違い、写しきれない |
| 人事・評価・給与の資料 | 人事の限定フォルダ | 人事責任者 | 年数回 | 人事と本人 | 入れない。誤って出たときの損害が大きい |
| 取引先ごとの契約・単価 | 営業の案件フォルダ | 営業責任者 | 案件ごと | 担当者と上長 | 入れない（第1段階）。案件管理の仕組み側で扱う |
この表の「持ち主」列が、後の更新運用の要になります。持ち主が「不明」の文書は入れません。誰も直さない文書は、入れた日から古くなり始めるからです。当社が見てきた範囲では、共有フォルダの手順書には長く更新されていないものが相当数混ざっていて、持ち主に確認すると「もう使っていない」と分かるものが出てきます。棚卸しの副産物として、使われていない文書が消えていく。これは AI を入れなくても価値がある作業です。
もう1つ、棚卸しで決めるのは「版」です。同じ規程の改定前と改定後、Word 版と PDF 版、部署ごとに少しずつ違う手順書の写し。これらが全部入っていると、AI はどれを根拠にするか選べません。IPA のガイドラインが「重複した情報」を精度低下の原因に挙げているのはこのためです。1つの文書には1つの正本を決め、正本以外は入れない。正本がどれか決められない文書は、持ち主に決めてもらうまで後回しにします。決められないのは AI の問題ではなく、社内で正本が決まっていないという業務の問題で、これも棚卸しで表に出ます。
権限の写し——元の置き場の閲覧権限を、検索にそのまま持ち込む
社内文書検索の本番判断で最初に詰まるのが権限です。共有フォルダでは部署ごと、社内 Wiki ではページごと、kintone ではアプリとレコードごとに閲覧権限があります。検索のために文書を1か所に集めると、この権限が消える。IPA のガイドラインは RAG の課題として「ベクトルDBに機密情報を含むデータを格納した場合、全てのユーザが機密情報を参照できる」「ユーザや部門ごとにRAGに格納するデータを分けることや、参照するデータに閲覧権限を設定することができない」、そして「従来の方法で上述の課題を解決するためにはRAGの環境を複数構築する必要があり、コストが高くなる」の3点を挙げています（2024年6月時点の記述）。同じガイドラインの第5章では、格納した情報の重要度ごとに参照できる利用者を設定し、管理職と一般社員で同じ質問に異なる回答が返る構成を、解決策の一例として示しています。
ベンダー側は、この問題に「置き場の権限をそのまま検索に効かせる」方向で答えています。Microsoft は Microsoft 365 の Copilot について「個々のユーザーが少なくとも閲覧権限を持つ組織データだけを表示する」と書き、SharePoint などの権限モデルを正しく使うことが前提だとしています。Google の Agent Search（旧 Vertex AI Search）は、データソースに閲覧できる利用者・グループの情報（ACL）を付けて検索結果を絞る機能を持ち、Google の ID と、Microsoft Entra ID や Okta などの外部 ID 基盤の両方に対応する。ただし、この権限制御はデータストアの作成時に有効にする必要があり、後から足せない、1文書あたりの閲覧者は3,000人まで、という制約も書かれています。OpenAI の文書検索（vector stores）には、文書ごとに最大16個の属性を付けて検索時に絞り込む機能があり、部署や機密区分を属性にして絞る作り方ができます。
当社は、権限の写し方を3つのパターンに分けて、発注側の環境と文書の閲覧範囲の細かさで選んでいます。
| パターン | やり方 | 向いている会社 | 落とし穴 |
|---|---|---|---|
| A 置き場の権限をそのまま使う | Microsoft 365 や Google Workspace の検索機能を使い、置き場の閲覧権限を検索がそのまま参照する | 文書がほぼ1つの基盤に集まっており、置き場の権限が整っている会社 | 置き場の権限が緩いと、そのまま検索に出る。導入前に「全社員に共有」になっている機密フォルダの棚卸しが要る |
| B 索引に閲覧範囲を写す | 取り込み時に文書ごとの閲覧範囲（部署・役職・機密区分）を属性として写し、質問者の属性で絞る | 共有フォルダ・Wiki・kintone など置き場が複数ある会社 | 置き場側で権限が変わったときに索引が追随しない。更新運用で「権限の変更」も引き金にする |
| C 閲覧範囲ごとに索引を分ける | 全社向け・部署向け・管理職向けなど、閲覧範囲の単位で索引を別に持つ | 閲覧範囲の種類が3〜5個で固定されている会社 | 文書が複数の索引に重複して入り、更新漏れが起きる。IPA が指摘する「環境を複数構築するとコストが高い」状態 |
どのパターンでも共通なのは、「権限を新しく設計しない」ことです。検索のために閲覧権限を1から決め直すと、部署ごとの調整に時間がかかり、その間は試作が止まったままになる。元の置き場の権限を正として写し、置き場側の権限がおかしければ置き場側で直す。この線引きは、受け入れ側の体制の記事で書いた「情シスが着任前に出す3つの一覧」のうち、権限の一覧をそのまま使う形になります。権限の一覧が無い会社では、まず全社員が見てよい文書（規程・全社手順）だけで第1段階を本番に入れ、部署ごとの文書は権限の一覧ができてから足します。
権限の写しを確かめる方法は「権限の違う2人の ID で同じ質問をする」ことです。一般社員の ID で管理職向けの文書が根拠に出たら不合格。当社はこの確認を、本番前のテストセットに「見えてはいけない質問」として必ず入れます。後述する評価の表でいう「権限越えの件数」で、合格基準は0件です。
根拠表示——「どの文書のどこか」を必ず出し、無ければ「分からない」と返す
回答に根拠を付けるかどうかは、社内文書検索が使われ続けるかを決めます。根拠が無い回答は、利用者が正しさを確かめられない。確かめるために結局元の文書を探し直すなら、最初から探したほうが早い、となって使われなくなる。IPA のガイドラインは「参照データの透明性」として、RAG を使う場合は参照したデータのパスを明示すること、参照元に誤りがあれば回答にも誤りが含まれるため「どのようなデータが参照されたのか確認し正誤を判断することが重要」と書いています。
ベンダーの機能もこの方向に揃っています。Anthropic の Claude API には、回答の各主張に対して元の文書のどの箇所を根拠にしたかを返す機能（Citations）があり、プレーンテキストなら文字位置、PDF ならページ番号、利用者側で区切った文書ならブロック番号で返す。Anthropic のドキュメントは、プロンプトで引用を指示する方法と比べて「引用は提供された文書への有効な参照であることが保証される」「Anthropic の評価では、最も関連する引用を選ぶ確率が有意に高い」と書いています。Google の Agent Search には、回答の文章と根拠にした文書を突き合わせ、どれだけ裏付けられているかを 0 から 1 の値で返し、主張ごとに根拠になった箇所を示す機能（Check grounding）があり、Microsoft の Copilot は利用者の質問と回答に加えて「回答の根拠に使った情報への引用」を記録に残すとしています。
ただ、根拠を付けるだけでは足りません。根拠が見つからないときに、AI がそれでも答えてしまうのを止める必要があります。Anthropic の「ハルシネーションを減らす」ガイドは、最初の対策として「分からない」と言う許可を明示的に与えること、長い文書を扱うときは先に原文の引用を抜き出させてから答えさせること、回答の各主張に裏付けの引用を探させ「見つからなければその主張を取り下げる」ことを挙げています。当社はこれを、社内文書検索の回答の型として次のように固定します。
| 回答の型 | 中身 | 利用者に見えるもの |
|---|---|---|
| 根拠が見つかった | 回答本文＋文書名＋該当箇所（ページ・見出し・行）＋その文書の最終更新日と持ち主 | 回答の下に「根拠 出張旅費規程 第4条（2026年4月改定・総務課長）」のような1行 |
| 根拠が部分的 | 見つかった範囲だけ答え、足りない部分は「この文書には書かれていない」と明示 | 答えられた部分と答えられなかった部分が分かれて表示される |
| 根拠が無い | 「該当する文書が見つかりませんでした」と返し、問い合わせ先（担当部署）を示す | 一般論の回答は出ない。担当部署の名前が出る |
| 見てはいけない文書が根拠 | その文書を根拠にせず、根拠が無い場合と同じ返し方をする | 「見つからない」と表示される。文書名も出ない |
最終更新日と持ち主を根拠に添えるのは、当社の追加項目です。利用者が「この文書は古いのでは」と気づけるのは、更新日が見えているときだけです。持ち主の名前が出ていれば、疑問があったときに聞きに行ける。根拠表示は、AI の回答を検証するためだけでなく、文書の持ち主に質問と修正が戻っていくための入口でもあります。
更新運用と評価——索引は「置いたら終わり」ではない
更新運用は持ち主の操作を引き金にする
試作と本番の最大の違いは、文書が変わり続けることです。IPA のガイドラインは「RAGの精度の維持には、ベクトルDBに格納されている情報の更新を定期的に行い、できるだけ最新かつ内容が重複しない状態に保つことが重要」と書いています。どう定期的にするかが設計の中身で、当社は「持ち主が正本を更新したら、取り込みが自動で再実行され、古い版が索引から消える」を原則にします。人が月に1回まとめて入れ直す運用は、その間ずっと古い回答が出続け、担当者が異動した月に止まります。
引き金は3種類です。文書の更新（正本の保存・改定）、権限の変更（閲覧範囲を変えた）、文書の廃止（正本を削除または「廃止」に変えた）。3つ目が最も忘れられ、廃止した規程が索引に残って「去年廃止した規程を根拠に答えた」症状になります。取り込みの仕組みは FDE が作りますが、引き金を引くのは文書の持ち主で、動いているかを月次で確かめるのは Echo 役です。Echo 役に渡す手順は、FDE が抜けた後も回る引き継ぎで書いた運用手順書の形式に合わせて、「更新が反映されていないと言われたときに確認する3か所」「廃止文書を索引から消す手順」「権限を変えたときの再取り込み」の3項目を必ず入れます。
AI のモデル側の更新も、索引と同じく運用の引き金になります。検索に使う埋め込み（文書を数値に変換したもの）のモデルが更新・廃止されると、索引を作り直す必要が出る。本番稼働後の AI はモデルの更新・廃止で壊れるに書いた版の固定と回帰テストは、社内文書検索では「索引の作り直し」を含めて計画します。索引の作り直しにかかる時間は文書量と仕組みで変わるので、当社は着手前に一度計測します。月次点検の項目には「使っているモデルの提供終了予定」を入れておきます。
評価は「探せたか」と「正しく答えたか」を分ける
評価の考え方は生成 AI の評価設計で書いた3層（出力の正しさ・業務上の受け入れ可否・運用上の安全）と同じですが、社内文書検索では第1層をさらに2段に分けます。検索で正しい文書を探せたか、探した文書をもとに正しく答えたか。分ける理由は、直し方が違うからです。検索で外れているなら、文書の切り方・索引の作り方・重複の整理を直す。検索は当たっているのに回答が違うなら、回答の指示や根拠の付け方を直す。混ぜて「精度80%」と測ると、どちらを直すか分かりません。
検索の当たり率の測り方は、Anthropic が2024年9月に公開した Contextual Retrieval（文脈付き検索）の記事が参考になります。この記事は評価指標を「関連する文書の切れ端が、検索結果の上位20件に入らなかった割合」（1 − recall@20）と定義しています。質問単位の当たり外れではなく、拾うべき切れ端の取りこぼし率です。この指標で、文書の切れ端それぞれに50〜100トークン程度の文脈説明を付けてから索引化する手法により失敗率が 5.7% から 3.7% に下がったこと、語の一致検索（BM25）を組み合わせると 2.9%、さらに並び替え（リランキング）を足すと 1.9% まで下がったことを報告しています。同じ記事には、文書全体が20万トークン（約500ページ）に収まるなら検索の仕組みを作らず全部をプロンプトに入れればよい、という記述もあり、規程集だけを対象にする第1段階ではこの選択肢が現実的な会社もあります。OpenAI の文書検索は、文書を既定で800トークンごとに区切り、隣り合う区切りを400トークン重ねて索引化すると書いており、切り方は設定で変えられる。数字はどれもベンダーの実験条件でのもので、社内文書でそのまま出る値ではありません。使うのは数字ではなく「検索の当たり率を測る物差しを先に決める」という型です。
| 段 | 指標 | 測り方 | 当社の合格の目安（第1段階・規程と全社手順） |
|---|---|---|---|
| 検索 | 検索の当たり率 | テストセットの各質問で、正解文書が検索結果の上位に入った割合 | 9割以上。外れた質問は文書の切り方か重複を疑う |
| 検索 | 権限越えの件数 | 「見えてはいけない質問」を権限の低い ID で投げ、根拠に出た件数 | 0件。1件でも本番に入れない |
| 回答 | 回答の一致率 | 現場が付けた正解と回答が一致した割合（部分一致は別に数える） | 8割以上。ただし誤りの重さで分けて経営が決める |
| 回答 | 根拠付き率 | 回答のうち文書名と該当箇所が付いていた割合 | 根拠が見つかった回答では10割 |
| 回答 | 文書に無い質問への誤答 | 「文書に無い質問」に対して一般論で答えてしまった件数 | 0件。「見つからない」と返すこと |
テストセットは、社員が実際にした質問から作ります。ヘルプデスクや総務への問い合わせ記録、チャットで「〜ってどこに書いてある？」と聞かれた記録を50〜100件集め、それぞれに正解文書と正解の回答を現場が付ける。ここに意図的に2種類を足します。「見えてはいけない質問」（一般社員が人事情報を聞く）と「文書に無い質問」（規程に書かれていないことを聞く）。この2種類が無いテストセットは、権限越えと誤答を測れないので、本番判断に使えません。上の表の数字は当社が第1段階で置く目安で、業界の標準値ではありません。合格の線を決めるのは FDE ではなく、検索の当たり率は情シスと現場、回答の一致率と誤りの許容は経営、権限越えの0件は情シスです。
FDE 方式での進め方——当社の標準6週間で第1段階を本番に入れ、索引の持ち主を Echo 役に渡す
当社が社内文書検索を FDE 方式で進めるときの標準は6週間です。規程と全社手順を対象にした第1段階を本番に入れ、部署ごとの文書は第2段階に回す。6週間の中で、上の4つ（棚卸し・権限の写し・根拠表示・更新運用）と評価をどの順で決めるかを表にします。
| 週 | FDE がやること | 発注側が決めること | 決める人 |
|---|---|---|---|
| 第1週 | 文書の置き場と権限の現状を見る。棚卸し表の6列を埋め始める。試作を1日で出し、動く状態で見せる | 入れない文書を先に決める。第1段階の対象を「全社員が見てよい文書」に絞る | 総務責任者・情シス |
| 第2週 | 正本と版を持ち主と一緒に決める。権限の写し方を A・B・C から選ぶ。根拠表示の型を実装する | 文書ごとの持ち主を確定する。持ち主不明の文書を入れない判断 | 各文書の持ち主・Echo 役 |
| 第3週 | 実際の質問からテストセットを作る（50〜100件）。見えてはいけない質問と文書に無い質問を足す | 正解の回答を現場が付ける。合格の目安を3者で決める | 現場・経営・情シス |
| 第4週 | 検索の当たり率と回答の一致率を測り、外れた質問ごとに切り方・重複・指示を直す。権限越えを2つの ID で確認 | 誤りの重さの許容を決める。権限越え0件を確認する | 経営・情シス |
| 第5週 | 更新運用（3つの引き金）を実装し、持ち主が実際に文書を更新して反映を確認する。運用手順書を書く | 更新の引き金を引くのが持ち主であることを、各持ち主の上司が了解する | Echo 役・各部署長 |
| 第6週 | 本番投入。利用者向けの「根拠を見てから使う」案内を出す。1週間の質問記録を見て、誤答と権限越えを毎日確認 | 本番投入の判断。第2段階（部署ごとの文書）の対象と順番 | 経営 |
この6週間で発注側に最も時間を使ってもらうのは第2週の「持ち主の確定」と第3週の「正解付け」です。どちらも FDE には代われません。持ち主が決まらない文書は入れない、正解が付けられない質問はテストセットから外す、と割り切ることで6週間に収まります。逆に、全部の文書を入れようとする、全部の質問に答えさせようとする、という方向に広げると、FDE の失敗パターン10に挙げた「対象を絞れずに PoC が終わらない」状態になります。
本番投入後、索引の持ち主は Echo 役です。Echo 役がやるのは3つ。月次で更新運用が動いているか確かめる（持ち主が更新した文書が反映されているか、廃止文書が消えているか）。質問記録から「見つからない」と返した質問を月に1回集め、文書が無いのか、あるのに探せていないのかを持ち主と分ける。新しく入れたい文書の申請を受け、棚卸し表に6列で追記する。FDE が抜けた後にこの3つが続いているかどうかが、社内文書検索が定着したかの指標になります。
まとめ
社内文書検索の試作は数日でできますが、本番に入れられるかどうかは検索の精度ではなく、文書の扱いと運用で決まります。入れない文書を先に決め、持ち主と正本を確定する棚卸し。元の置き場の閲覧権限を索引まで一緒に運び、権限の違う2人の ID で確かめる権限の写し。回答に文書名・該当箇所・更新日・持ち主を付け、根拠が無ければ「見つからない」と返す根拠表示。持ち主の更新・権限変更・廃止の3つを引き金に索引が変わる更新運用。IPA のガイドラインが挙げる RAG の課題（全員が機密を見られる、古い版と重複が精度を落とす、参照元が見えない）は、この4つに対応しています。
評価は「探せたか」と「正しく答えたか」を分け、実際の質問から作ったテストセットに「見えてはいけない質問」と「文書に無い質問」を必ず入れる。権限越えと文書に無い質問への誤答は0件が合格で、これは経営が緩めてはいけない数字です。FDE は第1段階を本番に入れ、索引の持ち主を Echo 役に渡して帰る。「規程を AI に読ませたい」という相談を受けたら、当社はまず「入れない文書はどれですか」と「その文書の持ち主は誰ですか」から聞きます。この2つが早く決まる会社ほど、当社の標準の6週間に収まります。決まらないまま範囲を広げれば、その分だけ延びます。
FDE を募集しています（会計FDE／FDE・業務システム）
経理の月次をAIで本番まで持っていく「会計FDE」（会計士・経理責任者・管理部門経験者）と、要件が固まる前に動くものを出して本番まで運ぶ「FDE（業務システム）」（ITコンサル・PM/PL・情シス出身者）を正社員で募集しています。応募でなくても構いません。まず30分の「キャリア相談」から。採用のお問い合わせフォームに「キャリア相談希望」と書いて送ってください。
「規程を AI に読ませたい」を、権限と根拠付きで本番まで設計します
文書の棚卸し（入れない文書・持ち主・正本の確定）、共有フォルダ・社内 Wiki・kintone の閲覧権限をそのまま検索に効かせる設計、文書名と該当箇所を必ず返す根拠表示、持ち主の更新を引き金にした索引の更新運用、実際の質問から作るテストセットと合格基準まで、貴社の文書の置き場と既存システムに合わせて設計します。経理 AX・kintone・案件管理システム刷新・Claude 導入で本番稼働まで伴走した経験をもとに、いま手元にある試作の権限と根拠を確かめるところから始められます。