非エンジニアが社内AIを作った構成と費用。資料の変換・実装例・運用の記録

社内AI 実践ノート 01｜全文無料

有用率の改善記録には一部の質問だけを再測定した回が含まれます。全36問を同じ版で採点した最新精度の証明ではありません。測定条件と比較の注意点は第4回に記載しています。

非エンジニアが社内AIを作った構成、資料の変換、運用で分かった失敗をまとめました。資料を揃える人、回答を直す人、検品の手順を決めてから小さく試すための記録です。

月約2,000円は当時の142回のAPI呼び出しに対する実測です。人件費や全社利用の総費用ではありません。本文の料金・モデル名・他サービスとの比較は当時の試行条件で、現在の仕様を比較した結果ではありません。

コードは説明用の抜粋です。loadPersona_、fetchFromDb_、canonBuildId_等の補助関数、認証、保存先は別途必要です。キャッシュの90×1024という分割幅は文字数であり、UTF-8のバイト上限を保証しません。保存前にバイト数を測り、読む時は全分割の存在・順序・内容を検証します。検証できなければ原本へ戻します。

資料を放り込んで「まあ、こんなもんか」で止まる

「AIを使え」と言われるようになりました。

社員全員が使い始めます。ただし、使い方はバラバラ。ある人は議事録の要約に使い、ある人はメールの下書きに使い、ある人は何に使えばいいか分からないまま放置している。

そのうち、誰かがこう思います。「社内の資料を読ませたら、もっと使えるんじゃないか」

そこで、手元の資料をまとめて放り込みます。NotebookLM でも、Gemini でも、同じことです。それらしい答えが返ってきます。 出典の番号まで付いています。

でも、微妙なんですよね。

答えが間違っているわけではない。でも欲しかったものとは違う。聞き方を変えても、資料を足しても、同じような答えが返ってくる。「まあ、こんなもんか」で終わる。

このままでは、全社員のAI活用やリテラシーは、一定水準のchatポチポチレベルで止まってしまう。もっと、社内のことを熟知して深いアウトプットが出てくるようなものが無いとダメだ。「ちゃんとしたものを作ろう」

調べると「RAG」という言葉が出てきます。社内の資料を検索して、質問に関係する部分だけをAIに渡す仕組みです。なるほど、それが必要らしい。

そして、それを請け負う会社が何社もあります。わたしも数社から話を聞いて、見積も見ました。

金額はここには書きません。ただ、社内の一担当が「とりあえず試してみます」と言える額ではありませんでした。 そして時間もかかる。数ヶ月以上。
そして一番のネックが
その請け負う会社で構築しちゃうと、使えるものが出来れば出来るほど、解約ができなくなる
これが、恐らく将来的に魚の骨が喉につっかかるような感じになりそうだなー、と。

しかも聞いていくと、こういう話になります。

……それ、社内でやるんですよね。

さらに厄介なのは、できあがったものが良いのか悪いのか、外部は判断できないことです。「精度85%です」と言われても、何の85%なのか分からない。社内の言葉づかいで答えてくれているのかも分からない。評価できないものに、大きな金額を払う判断ができない。

そこで止まります。多くの会社が、いまここで止まっていると思います。

外注する「RAG」を3つに分解したら

わたしが最初に引っかかったのは、そこでした。

分解してみたら、3つでした。

中身 誰がやれるか
① 読ませる資料を整える → 社内しかできない
② 資料を検索して、関連部分をAIに渡す → 既製品がある
③ どう答えるか（振る舞い）を決める → 社内の言葉が要る

①と③は、外注しても社内がやります。 資料を持っているのは社内で、「うちではこう答えてほしい」を言えるのも社内だけです。

つまり、払っているお金の大半は②の代金です。

……という計算をしていたのですが、本当の理由は費用ではありませんでした。

自分で作ると決めた最終的な理由は、費用ではなく「直す速さ」

作ってみて分かったことを先に書きます。

社員が使えるものにするために必要だったのは、機能ではなく「出力の直し」でした。

1ヶ月のうち、わたしがいちばん頻繁にやっていたのは、こういう作業です。

• AIが「〜してあげる」という言い方をした → 現場ではその表現を使わない。禁止する

• 相談者の等級が分からないのに「あなたは◯◯等級だから」と断定した → 推測で断定するな。先に1つだけ聞け

• 「見通しを立てましょう」と返した → それは目標の言い換えで、行動ではない。明日の予定表に書ける形にしろ

• 社外の人に伝えるセリフとして、事実と違う会社の体制を語った → サービス内容と人員配置を断定するな

どれも、実際に使われて、実際に指摘されてから直したものです。

そして重要なのは、1つ直すと別のところが崩れることです。禁止を足したら、AIが何も言わなくなった。指示を増やしたら、大事な指示が埋もれて効かなくなった。足し算ではなく、順序と量の調整でした。

ある日は、1日で出力ルールを10個変えました。

これを外注でやれるでしょうか。

「この言い方をやめてください」と依頼して、修正されて、確認して、また指摘する。1往復に何日かかりますか。 そのあいだ、社員は微妙なAIを使い続けます。そして微妙なAIは、二度目は使われません。

社内AIの品質は、直した回数で決まります。 機能の数ではありません。

回転数が品質を決めるなら、自分で回すしかない。

そう思って、自分で作ってみるか、となりました。それが動機です。費用の話は、後から付いてきたおまけでした。

最初の壁は技術ではなく「社内資料が文字になっていない」こと

作り始めて、すぐ固まりました。

社内の資料は、文字になっていません。

• 評価の基準は、行が項目・列が等級のマトリクス表でした

• 組織と役割の関係は、組織図でした

• 事例集は、Excelの表でした

• 規程と権限は、PDFでした

• そして評価基準の原本は、デザインソフトのアウトラインデータでした。文字として取り出せません

社内資料は、人間が目で見て理解するために作られています。 レイアウト、罫線、セルの結合、矢印、色。情報の半分が「配置」に入っています。

これをコピーしてAIに渡すと、こうなります。

,,,行動,,下位等級での判定,,中堅での判定,,管理職層での判定
,,他責にするだけ・解決行動なし,,,,,,

意味が消えます。 人間が見れば一瞬で分かる表が、テキストにした瞬間にただの記号列になります。

この方式で本当に必要だったのは「図と表を文字に翻訳すること」でした。 そしてこれが、プロジェクトでいちばん時間を使った作業です。

表をどう1行に展開するか、図から何を落として何を残すか、PDFの壊れた表をどう直すか、そしてコピーすらできないデータをどう扱うか。ここは全部、手を動かして決めたことなので、後半で具体的に書きます。

先に結論だけ書いておくと、この作業はAIに手伝わせられます。 ただし1箇所だけ検算を入れないと、AIが表の一部を黙って落とします。わたしは実際に落とされて、気づかずに使っていました。

資料は6万5千字。検索の仕組みは作らずに済んだ

文字にし終わったら6万5千字でした。

ここで気づきました。今回使った環境では、6万5千字の資料を入力できました。入力上限と回答品質はモデル・設定・資料によって変わります。

冒頭に書いた「RAG」は、資料が多すぎて一度に渡せないから、検索して一部だけ渡す仕組みです。逆に言えば、一度に渡せる量なら、検索は要りません。

やってみました。動きました。

資料 65,000字 ＝ 約39,000トークン
1回の質問あたりの費用 ＝ 約15円
1ヶ月の実測費用 ＝ 約2,000円（142回の呼び出し）

検索の仕組みを作っていません。毎回、13ファイルの中身を全部つなげて、まるごと渡しています。

数字を出しておきます。使ったモデルは Gemini 3.1 Pro で、入力が100万トークンあたり$2.00、出力が$12.00です。1ヶ月の実測は、入力5,386,290トークン・出力226,468トークン、合計 $13.49。円換算で2,000円くらいです。

社内AIを1ヶ月動かして、2,000円でした。

そして、これがさっきの「回転数」の話に繋がります。検索の仕組みが無いので、直すのが速いんです。 資料を差し替えたら次の質問から反映される。出力ルールを変えたければ、テキストを1行足すだけ。検索の精度を調整する作業が、そもそも存在しません。

この方式が成り立つ3つの条件

正直に境界線も書きます。この方式が成り立つのは、こういう条件のときです。

• 資料が 10万字以内（文庫本1〜2冊ぶん）

• 資料の更新が頻繁でない（毎日書き換わるものには向かない）

• 1回あたり20〜30秒待てる（全部読ませるので、その分遅い）

うちは全部当てはまりました。だから作れました。

逆に、この境界を超えると本当に検索が必要になります。 わたしはいま別のものを作ろうとしていて、そちらは対象が375万字あります。全部渡すのは無理です。素直に検索の仕組みを作ります。

つまり「RAGは要らない」という主張ではありません。「資料が少ないうちは要らない」です。 そして多くの社内用途は、思っているより資料が少ないです。

まず全部渡してみて、入らなくなってから考える。 逆順にすると、動くものが1つも無い状態で数ヶ月を使うことになります。

NotebookLM でいいんじゃないの？と思っていました

ここが本題です。わたしも最初はそう思いました。

違いました。 そして違いは「精度」ではありませんでした。

実際に起きた事故2件（教材400件／休業制度の誤回答）

1つめ。教材の一覧表を入れて、微妙に終わった話。

ある部門が、社内の教材400件あまりの一覧表を NotebookLM に入れて、「この人にはどの教材がいいか」を答えてくれるようにしようとしました。結果はかなり微妙でした。

原因は3つあって、下の2つはツールを変えても直りません。

• 渡していたのが一覧表で、教材そのものではなかった。表にはファイル名・種類・リンクが並んでいた。この試行では、一覧表のリンク先の教材本文まで取り込まれていませんでした。 つまり知っていたのは400件のファイル名だけで、できることは文字列マッチングだけ。そして出典番号が付くので、根拠があるように見えます

• 教材の実物を開いたら、中身はワークシートそのもの。「誰向けか」がどこにも書いていなかった。 教材は「何を教えるか」の資料で、「誰に向くか」を結んでいるのは現場の人の頭の中でした。手元の資料からは原理的に答えが出ません

• 400行の似た形の表は、この種類のAIがいちばん苦手なデータ。どの行も同じ形をしていると区別がつきません

2つめ。これが本当に効いた事故です。

別の部門が、会社の規程・規約を読み込ませた NotebookLM を、管理部の問い合わせ用チャットボットとして社内に展開していました。

そこで、ある社員が聞きました。「アルバイトも、この休業制度を使えますか」

AIは「使えます」と答えました。

社員はそれを信じて、アルバイトの方にそう伝えました。

総務に確認したら、「使えません」でした。

アルバイトの方に、嘘を伝えてしまいました。

――この事故の何が怖いか。誰も、間違いに気づいていなかったことです。

AIは自信を持って答えました。聞いた社員は疑いませんでした。そして、もし総務に確認する流れがなかったら、この間違いは永久に発見されませんでした。

そして、間違いを見つけた人が、それを報告する場所がありませんでした。

「あのボットの答えが違っていた」と伝える先が無い。伝えたとしても、誰がどう直すのかが決まっていない。 だから、同じ質問には、明日も同じ嘘が返ります。

これが、わたしが自分で作ることを決めた最大の理由です。

わたしのAIには、回答のすぐ下に「👎 ここが違う」というボタンを置きました。押すと、その場で「何が違ったか」を書く欄が出ます。 書かずに送ることもできます（強制すると、面倒がって押すのをやめる人が出るので）。

そして、それがどの回答に対するものかを紐づけて記録します。「badの3文字」だけが集まっても、何も直せないからです。

1ヶ月で6件のコメントが集まりました。そのうち4件は、AIの間違いではなく「会社の資料に、その情報が無い」ことが原因でした。 これは直せます。資料を足せばいい。でも、報告する場所が無ければ、永久に分からないままでした。

NotebookLM では届かなかった4つのこと

原因を潰したうえでも、NotebookLM では届かないものがありました。

① 振る舞いを蓄積できない

さきほど挙げた「〜してあげるを使わない」「等級を推測で断定しない」は、全部、事故が起きたあとに足したものです。

同じ事故を二度起こさないための指示を、資料として溜められるかどうか。 ここが決定的でした。NotebookLM では、毎回自分でプロンプトに書くしかありません。書き忘れたら、事故が再発します。

② 間違いを報告する場所を作れない

さきほどの事故です。これは「AIの性能」ではなく「仕組みの有無」の問題です。

③ ログが取れない

誰が、何を聞いて、AIが何を答えたか。これが残らないと何も直せません。

うちは1ヶ月で111件のやり取りが溜まりました。読んだら、AIが「その資料は入っていません」と答えた回答が14件ありました。

これは、社員が会社に聞きたいのに、答えが用意されていない項目のリストです。しかもよく聞かれる順に並んでいます。

④ 測れない

出力ルールを変えたとき、良くなったのか悪くなったのかを判定する必要があります。同じ質問を同じ経路で流して採点する仕組みを、自分で作れる。当時は、同じ経路で再実行し、記録する仕組みを自分で用意しました。

副産物：制度で言語化されていない箇所が14件、リストで出てきた

これは作る前には想像していませんでした。そして、いま振り返るといちばん会社のためになった部分かもしれません。

AIを入れたら、会社の制度で言語化されていない箇所が、リストになって出てきました。

さきほどの14件です。社員が実際に聞いて、AIが「資料に無い」と答えたものです。

• 長期の休職から復帰したあと、評価はどう扱われるのか

• 「コスト意識を持て」と言われたが、具体的に何の数字を見ればいいのか

• 上の等級に昇格するために、具体的に何が必要なのか

• 感染症で休んだとき、いつから出勤できるのか

どれも、答えが用意されていませんでした。 制度としては存在するのに、社員が読める形で言語化されていない。

そして重要なのは、これがアンケートでは絶対に出てこないことです。

社員アンケートで出てくるのは「評価制度が分かりにくい」という点数と感想です。それだと何を直せばいいか分かりません。AIのログに残るのは、実際の質問文そのものです。 しかも、実際の質問を確認できます。頻度順にするには分類と件数の集計が別途必要です。

「制度が分かりにくい」と「休職復帰後の評価の扱いが決まっていない」は、まったく別の情報です。 後者には、明日から着手できます。

さらにもう1つ。判定基準そのものが存在しない評価項目も見つかりました。項目名だけがあって、「どういう状態が良いのか」が定義されていない。AIに読ませようとして、初めて気づきました。

AIに読ませるという作業は、制度の棚卸しでもありました。

社内AIを検討している人には、この副産物のほうを推したいくらいです。回答の質より、答えられなかったことのリストのほうが価値がありました。

Google Apps Script を選んだ3つの理由

あと今回の仕組みはGoogle Apps Script で作りました。

「え、それ？」と思われるかもしれません。理由は3つあって、どれも技術的な優劣の話ではありません。

1つめ。認証を作らなくていい。

社内ツールでいちばん面倒なのはログインです。誰がアクセスしているかを、なりすまし不可能な形で知る必要がある。Apps Script のウェブアプリは、これをタダでやってくれます。 会社のドメインにアクセスを限定し、実行ユーザーと権限設定を合わせて確認しました。ユーザー識別は公開設定・実行条件に依存するため、別のアカウントでも実機で確認します。

評価の相談を扱うので、ここを自作したくありませんでした。

2つめ。URLを配るだけで配布が終わる。

サーバーを立てない。ドメインを取らない。デプロイしたらURLが1つ出てくるので、それをチャットに貼る。5日で11人に配れました。

3つめ。資料の差し替えを、非エンジニアができる。

これが最大の理由でした。資料は共有ドライブのフォルダに置いてあります。フォルダに文書を放り込めば、次からAIが読みます。

わたしがいなくても、資料を増やせる。社内ツールで、これができないと死にます。 作った人が抜けた瞬間に更新が止まって、半年後には嘘を答えるAIになります。

1ヶ月の実測：2日で101件、費用は月2,000円

初速は出ました。

配ってからの日別の数字です。

質問数：使った人
配布1日目：質問2件 / 1人
2日目：質問60件 / 8人
3日目：質問41件 / 10人
土日：0件 / 0人
4日目：質問8件 / 4人
5日目：質問0件。 3人が開いて、1問も打たずに閉じた

2日で101件です。 10人が触って、👎のコメントが6件つき、制度の穴が14件見つかりました。回答の有用率も、自分で作った36の質問セットで測って 75.0%から94.4% まで上がりました。費用は月2,000円でした。

動いたし、使われました。

そのうえで、いちばん重い数字がこれです。

3日以上続けて使った人は、1人でした。わたしです。

「使われない」と「使われ続けない」は、別の問題です

わたしは最初、これを「使われなかった」と受け取りました。違いました。

配った直後は、みんな使います。新しい道具は面白いし、頼まれれば試してくれます。初速は、道具の出来とはあまり関係なく出ます。

止まるのは、そのあとです。

4日目の8件を読み返して、はっきり分かりました。そのうち6件は「お前は何を知っているんだ」を確かめる質問でした。

困りごとの相談ではありません。性能試験です。 そして残り2件は、画面に例文として置いた質問を、そのまま押しただけでした。

自分の言葉で困りごとを打った人は、3日目以降ほぼいません。

続かない理由は、道具の質ではなかった

品質は上げました。測って上げました。それでも続かない理由が、途中で分かってきました。

「相談する」という行為に、使う理由が毎月やってこないんです。

評価やキャリアの悩みは、いつでもあるように見えて、実は「言葉にして相談しよう」と思う瞬間が滅多に来ません。 面談の前と、何かに腹が立った直後くらいです。

つまり、使う理由を道具の側で作れていませんでした。

「困ったら来てください」という道具は、困っていない日は開かれません。そして人は、困った日に道具のことを思い出しません。

次は「毎月必ず来る業務」に入れる

いま別のものを作っています。経費精算です。

うちの会社では、毎月100人以上が、Excelのフォーマットをコピーして、日付と経路と金額を手で入力して提出しています。1人あたり20分くらいです。

計算すると、年間440時間。人件費に換算すると100万円を超えます。

そして、ここが決定的なのですが、

経費精算は、毎月必ず来ます。

思い出さなくていい。困っていなくても来る。業務が、使う理由をこちらに渡してくれます。

領収書を撮って送ると、金額と日付と支払先が読み取られて、フォーマットに入って出てくる。交通費は、日付と駅を並べて書くだけで、過去の実績から金額が入る。最後に自分で少し直して提出する。

「相談に来てもらう道具」から「作業を代わりにやる道具」へ。 ここが、いまわたしが立っている場所です。

社内AIを作る人に、いちばん伝えたいのはこれかもしれません。

私の試行では1ヶ月で動くものを作り、APIの実測費用は約2,000円でした。期間・費用・改善幅は条件によって変わります。

それでも、使い続ける理由は、道具の外から持ってこないといけません。

この続きは、連載の後半で書きます。

この連載で書くこと（黙って失敗していた箇所10件）

わたしは専業のエンジニアではありません。事業側の人間が、業務の合間に作った記録です。

だから「うまくやった話」は書きません。同じ穴に落ちる人を1人でも減らすための記録として書きます。1ヶ月で見つけた「黙って失敗していた箇所」は10件あって、10件すべて、エラーは1件も出ませんでした。

• 1ヶ月間、資料の2割が読み込まれていなかった

• 安全のための禁止ルール20件が、0件で動いていた

• AIが存在しない社内制度を創作して、堂々と提示した

• 資料が1文字も無い領域を、AIが詳細に語っていた

• 別の自動処理が、2ヶ月間、毎日失敗し続けていた

システムは動いていました。画面はきれいで、AIはよく喋り、それらしい答えを返していました。動いているように見えることが、いちばん危険でした。

ここから先は、実際の作り方を書きます。

「自分でも作れるかも」と思った人が、明日から手を動かせる状態まで持っていきます。

全体構成（部品は4つだけ）

まず全体像です。部品は4つしかありません。

[ 共有ドライブのフォルダ ]        ← 資料。非エンジニアが差し替える
          ↓ 取り込み（1日1回 or 手動）
[ 資料を溜めるデータベース ]      ← 読めた/読めなかったを記録
          ↓ 起動時に読む（キャッシュ）
[ ウェブアプリ（Apps Script）]    ← 画面・プロンプト組み立て・ログ記録
          ↓ HTTPで呼ぶ
[ AIのAPI ]

ポイントは、取り込みと利用を分けていることです。最初は「使うたびにDriveを読む」形にしていましたが、これは失敗でした。理由は後で書きます。

何を読ませたか（ファイル名をそのまま出します）

参考になると思うので、実際に入れている資料を並べます。社名や制度名が出ない範囲で、名前はほぼそのままです。

資料/
├ 00_共通/
│   ├ 会社の基本と等級                          1,356字
│   └ いま答えられないこと（未収録の資料一覧）      3,500字
│
├ 10_申請と決裁/
│   └ 申請と決裁のルール（職務権限表より）         2,612字
│
├ 20_評価軸/
│   ├ 行動規範と価値観のハンドブック（抜粋）      15,047字
│   ├ 評価基準（人事確認済み）                  12,483字
│   ├ 会社の考え方（社員コメントへの回答より）      5,538字
│   ├ 等級別の評価項目と配点                     3,901字
│   ├ 相談テーマと評価軸の対応表                 1,686字
│   └ 等級と給与レンジ                          1,087字
│
├ 30_事例/
│   ├ 事例集（20件）                           9,631字
│   └ 事業部が求める人材（異動・キャリア相談用）    3,391字
│
└ 90_人格/
    ├ システムプロンプト                        2,255字
    └ 補足指示（回答の作り方）                   2,662字

13ファイル、合計6万5千字。文庫本1冊ぶんもありません。

いくつか、名前について補足します。

「いま答えられないこと（未収録の資料一覧）」 ——これが効きました。「知識ベースに何が無いか」を明示した資料です。「この話題を聞かれたら、推測で答えず、無いと正直に言って、確認先を示せ」と書いてあります。あとで詳しく書きます。

「会社の考え方（社員コメントへの回答より）」 ——社内アンケートで出た疑問に、会社が公式に回答した内容です。制度の条文よりも、こちらのほうが相談に効きました。 「なぜそうなっているのか」が書いてあるからです。

「相談テーマと評価軸の対応表」 ——これは自分で作りました。「こういう相談が来たら、この評価項目の話だ」という対応表です。AIが的外れな評価軸を持ち出すのを防ぐために足しました。

「補足指示（回答の作り方）」 ——出力の形を書いた資料です。ここに、さきほどの「〜してあげるを使わない」などが溜まっていきます。事故が起きるたびに1行増える場所です。

うちには無かったが、あれば入れたほうがいいもの

うちは「評価とキャリアの相談」に絞ったので入れていませんが、あれば強力だと思うものを挙げておきます。

• 各部門のKPIと、その定義（何をどう数えているか。定義が言語化されていない会社が多い）

• 予算と実績の枠組み（「コスト意識を持て」と言われた社員が、何の数字を見ればいいか分かる）

• 業務手順書（SOP）

• 商品・サービスの一覧と価格体系

• 過去の問い合わせ履歴とその回答（これは後述しますが、いちばん価値が高い可能性があります）

• 稟議・決裁の過去事例（「これは誰の決裁が要るか」に答えられる）

• 安全衛生・コンプライアンスの基準

逆に、絶対に入れなかったものも書いておきます。

• 個人の評価結果、給与額、面談記録

• 1on1の生データ

• 社員アンケートの実名・コメント原文

• 未公開の経営計画

「社員なら誰が見てもいい情報」までが、入れてよい線でした。 個人のデータを混ぜた瞬間に、「他人の情報を聞き出せるAI」になります。ここは1行も妥協しませんでした。

図と表を文字にする（ここが一番時間を使った）

表を文字にする（4つの手順）

無料部分で「1行1文に展開する」と書きました。実際の手順を書きます。

手順1：表の「軸」を確定させる

まず、その表が何と何の掛け算なのかを決めます。

評価基準の表 ＝ 【評価項目】×【等級】×【評価段階】
職務権限表   ＝ 【手続きの種類】×【対象の区分】→ 決裁者
給与レンジ表 ＝ 【等級】→ 下限・上限

ここを間違えると全部やり直しになります。 そして「3つの掛け算」になっている表が、いちばん厄介です。人間は3次元の表を平面に潰して読めますが、テキストにすると1つ次元が消えます。

手順2：1行のテンプレートを決める

軸が決まったら、1行の書式を固定します。

【テンプレート】
{評価項目}／{等級}／{段階}：{記述}

【出力】
・目標達成への姿勢／下位等級／最低評価：他責にするだけで、解決に向けた行動がない
・目標達成への姿勢／下位等級／標準：原因を自分に求めることができている
・目標達成への姿勢／下位等級／最高評価：改善案を提案し、周囲を巻き込んで実行している

必ず「／」などの区切り記号を使って、機械的に読める形にします。 自然な日本語にしないほうがいいです。「下位等級の目標達成への姿勢については、最低評価の場合は…」と書くと、AIが文脈を取り違えます。箇条書きの機械的な形が、いちばん正確に伝わりました。

手順3：AIに変換させる。ただし検算する

100行の表を手で打つのは無理です。AIに変換させます。

わたしが使ったプロンプトは、こういう形です。

以下は社内資料の表をCSVに書き出したものです。
これを、1行1文の箇条書きに展開してください。

【書式】
{評価項目}／{等級}／{段階}：{記述}

【ルール】
- 元の記述を要約・言い換えしないこと。原文をそのまま使う
- 空欄のセルは「（記述なし）」と書く。飛ばさない
- 出力行数は、必ず {項目数} × {等級数} × {段階数} 行になるはず
- 最後に、出力した行数を報告してください

【CSV】
（ここに貼る）

肝は最後の2行です。

`{項目数} × {等級数} × {段階数}` を先に計算して書いておく。そして出力行数を報告させる。 これで、取りこぼしが即座に分かります。

わたしはこれをやらずに1回失敗しました。AIが空欄のセルを黙って飛ばして、行数が合わないまま気づかず使っていました。 表の一部が消えていました。

「飛ばさない。空欄も1行書く」を明示してください。 そして数を数えてください。

手順4：表の「読み方」を人間が書き足す

これは自動化できません。その表が何を言おうとしているのかは、表の中に書いていないからです。

わたしが書き足したのは、こういう文です。

★ この表の読み方
・等級が上がると、判定基準が1段ずつ厳しくなる。同じ行動でも上の等級では評価が下がる。
　これは制度の設計思想であって、不公平ではない
・「記述なし」の項目は、その等級では評価対象になっていない。
　評価対象外の項目を持ち出して助言しないこと

2つめが重要です。 「空欄＝評価対象外」という意味を書かないと、AIは空欄を「情報が無いだけ」と解釈して、勝手に他の等級の記述を持ってきます。実際に起きました。

図を文字にする（落としてよいもの／いけないもの）

組織図やフロー図は、そのままでは文字にできません。 情報が落ちます。

だから、落としました。ただし、落としてよいものと落としてはいけないものを分けました。

【落としてよかったもの】
・ボックスの位置関係、色、線の太さ
・部署名の網羅（相談に出てこない部署は要らない）

【落としてはいけなかったもの】
・階層の上下（誰が誰の上か）
・「どの役割が、どの決裁権を持つか」
・呼び方のルール（社内で何と呼んでいるか）

そして1つ、図には無いのに書き足したものがあります。

・制度上必要な管理者は、行政に届出する別の概念。等級とは無関係

「無関係」と書いたのが大事でした。 図では離れた場所に描かれているので人間は混同しませんが、文字にすると近くに並ぶので、AIが繋げてしまいます。 「これとこれは関係ない」を明示する必要があります。

PDFを文字にする

抽出ツールで文字は取れます。表が壊れます。

罫線が消えて、セルの中身が改行で繋がって、どの行のどの列だったか分からなくなります。そして壊れていることに気づかないまま渡すと、AIが平然と嘘を答えます。

なので、抽出した後に必ず目で見ました。 これは自動化できませんでした。

いちばん怖かったのは、原本ではなく自分の変換コードでした

これは記事を書いたあとに分かったことなので、追記します。

ある日、AIが「別の等級の配点」を持ち出して答えました。わたしはプロンプトのルール不足だと判断して、「配点は等級ごとに違う」「等級が分からないときは数字を出さない」を書き足しました。

直りませんでした。

原因を体系的に洗ったら、表そのものが表として成立していませんでした。

	経営リスクを予見して対応する
	          ← 空セルなので、タブだけの行
              ← さらに空行
	●
	●

埋まっているセルは1行、空のセルは2行になっていました。つまり、25行×5列の表を「空行の数を数えて復元する」しかない状態です。タブだけの行が79本ありました。

もっと悪いものもありました。節の見出しが、データ行の6番目のセルに見える形になっていたことです。節の境界が消えていました。

壊していたのは原本ではなく、わたしが書いた取り込みコードでした。

そして重要なのはここです。症状は「AIが間違える」という形で出ます。 だからプロンプトを疑います。ルールを足します。直りません。また足します。

AIの間違いを見たとき、最初に疑うのは自分の変換コードです。 プロンプトは最後です。

目視で読み取ったものには、印を付ける

いちばん苦労したのが、デザインソフトのアウトラインデータでした。文字が図形になっているので、コピーもできません。

画像にして、目で読んで、手で打ちました。

当然、読み間違いが混ざります。だから資料の先頭に、こう書きました。

出典：（原本の名前）
時点：2024年〜適用
最新か：最新
更新責任者：人事
未確認：⚠ 上位等級版は、項目の並びが別の資料と一部食い違う
　　　　⚠ 一部の項目は原文が読み取れていない

「読み取れていない箇所がある」と、資料そのものに書きました。

これが後で効きました。AIが答えられなかったとき、それが「AIの不調」なのか「そもそも資料に無い」のかを、即座に切り分けられます。

目視で作った資料は、目視で作ったと書く。 これをやらないと、半年後の自分が「これは正確な原本だ」と信じます。

画像をそのまま渡す選択肢を捨てた理由

いまのAIは画像を読めます。だから「表の画像をそのまま渡せばいいのでは」と思いました。

やめました。 理由は3つです。

1. 毎回渡すと高い。 画像は文字よりトークンを食います

2. 読み取り結果が毎回変わる。 同じ表を渡しても回答が揺れます。再現しません

3. 間違いを直せない。 読み取りを間違えていても、こちらから訂正できません

一度テキストに落として固定するほうが、安く、安定し、直せます。

画像を渡すのが向いているのは、毎回違うものを読む場合です。領収書とか、手書きのメモとか。同じ資料を何度も読ませるなら、テキストにして固定するのが正解でした。

資料をまるごと渡す実装

やっていることは、驚くほど単純です。

function buildSystemPrompt_(room, profile, rules) {
  return [
    loadPersona_(),                        // どう答えるか（人格・口調）
    '\n\n### いまの部屋：' + room.name,
    room.guidance,                         // この相談で何をするか
    loadCanon_(room.sources),              // ★資料をまるごと。6万5千字
    ngRulesForPrompt_(rules),              // 過去の事故から足した禁止ルール
    '\n\n### 相談者について\n' + who(profile),
    '\n\n### 出力の形',
    outputRules_(room)                     // 回答の作り方
  ].filter(String).join('\n');
}

`loadCanon_()` が資料を全部つなげて返します。それだけです。 検索はありません。

相談の種類で読む資料を切り替える（費用が6割減った）

全部渡すといっても、全種類の相談で全部の資料を渡す必要はありません。

フォルダ名の先頭に番号を付けて、相談の種類ごとに読むフォルダを指定します。

var ROOMS = {
  soudan:  { name: '仕事の困りごとを相談', sources: ['00_', '20_', '30_'] },
  mendan:  { name: '評価面談の準備',       sources: ['00_', '20_', '30_'] },
  shinsei: { name: '申請書類をつくる',     sources: ['00_', '10_'] }
};

この切り替えが、費用と速度に直結します。

上のファイル一覧を見てください。評価軸だけで39,742字、全体の61%です。 「申請書類をつくる」の相談では、評価軸を読む必要がありません。読まなければ、その相談だけで6割減ります。

部屋を分けることが、そのまま費用削減になります。 検索を入れる前に、まずここです。相談の種類で切るのは、検索の仕組みを作るより圧倒的に簡単で、間違いようがありません。

キャッシュに入れる。ただし鍵に「版」を混ぜる

毎回Driveを読むと遅すぎるので、キャッシュに入れます。ここで一箇所だけ工夫が必要でした。

function loadCanon_(prefixes) {
  var buildId = canonBuildId_();                    // ★資料の版
  var key = 'canon_' + prefixes.join('') + '_' + buildId;
  var hit = CacheService.getScriptCache().get(key);
  if (hit) return hit;

  var text = fetchFromDb_(prefixes, buildId);
  putChunked_(key, text);                           // 分割して入れる
  return text;
}

キャッシュの鍵に、資料の版（buildId）を混ぜています。

理由は、資料を取り込み直したときに古いキャッシュを消し忘れるからです。実際に消し忘れて、更新したはずの資料が反映されない状態を作りました。

「消してもらう」ではなく「変わったら別の鍵になる」形にすれば、消し忘れが原理的に起きません。 取り込み処理が別のプログラムになっている場合、特に効きます。あちらからこちらのキャッシュは消せないので。

キャッシュに入りきらないのに、エラーが出ない

もうひとつ罠があります。Apps Script のキャッシュは、1つの値に入れられるサイズに上限があります。

6万5千字は入りません。そして、入らなかったときにエラーが出ません。 静かに保存されず、次回また原本を読みます。動くので気づけません。

なので、分割して入れます。

function putChunked_(key, text) {
  var size = 90 * 1024;                 // 安全側に取る
  var n = Math.ceil(text.length / size);
  var cache = CacheService.getScriptCache();
  for (var i = 0; i < n; i++) {
    cache.put(key + '_' + i, text.substr(i * size, size), 21600);
  }
  cache.put(key + '_n', String(n), 21600);   // ★個数は最後に書く
}

`_n`（個数）を、いちばん最後に書くのが肝です。

読む側は、`_n` が無ければキャッシュ無しとして扱います。こうすると、途中まで書かれた状態で読み出す事故が起きません。 3つ書いたところで止まったら、`_n` が無いので全体が無効になり、素直に原本から読み直します。

「完了の印を最後に書く」は、このあと何度も出てきます。 この1ヶ月で学んだことの中で、いちばん応用が効いた考え方でした。

費用の計算式

見積が要るときに使える形で書いておきます。

1回の費用 ＝ 資料の文字数 ÷ 1.67 × 入力単価 ＋ 回答の文字数 ÷ 1.67 × 出力単価

`1.67` は日本語の文字数からトークン数への換算です。実測値です。 資料65,000字が約39,000トークンでした。モデルによって変わるので、自分の環境で1回測ってください。

わたしの実測を当てはめると、こうなります。

入力： 39,000トークン × $2.00 / 1,000,000 = $0.078   （約12円）
出力：  1,600トークン × $12.00 / 1,000,000 = $0.019  （約3円）
                                   1回あたり 約15円

そして月の費用は、呼び出し回数で決まります。

月の質問数 → 月の費用（概算）
月150回 → 約2,000円
月1,000回 → 約15,000円
月3,000回 → 約45,000円

社員600人が月5回使っても、月45,000円です。 構築費と比べてください。

社員600人が月5回使っても、月45,000円です。 構築費と比べてください。

費用の8割は入力（節約できるのは1箇所だけ）

わたしの実測では、$13.49のうち$10.77（80%）が入力でした。

1回あたり39,000トークンの入力に対して、社員が打つ質問は平均40文字です。送っているものの99.9%が、毎回同じ資料です。

つまり、節約したいなら「送る資料を減らす」以外にありません。 出力を短くしても効きません。ここが効くと分かっているだけで、無駄な最適化を避けられます。

減らし方は4つあり、費用対効果の順にこうです。

1. 相談の種類で読む資料を切り替える（前述。うちなら6割減。品質は落ちない）

2. 同じ入力をキャッシュする仕組みを使う（プロバイダ側の機能。入力単価が1/10になる）

3. 資料そのものを削る（ここから先は品質と引き換え）

4. 検索（RAG）を入れる（いちばん効くが、いちばん壊しやすい）

検索は最後です。 これが今回いちばん伝えたいことです。

検討して捨てた選択肢3つ

表計算ソフトにログを書く → 捨てた

最初はこうしていました。理由は簡単で、Apps Script から一番書きやすいからです。

構造的に無理でした。

利用者本人の権限で書き込む形にすると、書き込み権限を全員に渡す必要があります。 そして書き込めるということは、開いて読めるということです。

評価の悩みを書き込む場所を、全員が読める状態にはできません。

サービスアカウントが分析用データベースに書く形に変えました。これで「本文を保存するが、読めるのは運営担当だけ」が技術的に成立します。表計算ソフトでは原理的に成立しません。

利用者の権限でDriveを読む → 捨てた

これは配布した後に指摘されて気づきました。

社員から質問が来ました。「自分のアカウントで許可したら、マイドライブの中も読み込まれるのか」

そのときの答えは「読める権限はあるが、コードは読んでいない」でした。約束であって、事実の記述ではありません。 そしてコードを1行足せば、いつでも読める状態でした。

評価やキャリアの悩みを預ける道具の入口で、約束を信じてもらう作りにしてはいけません。

だから資料を読む処理を、別のプログラムに全部移しました。 利用者が使う側には、Driveを読むコードを1行も残していません。

結果、承認画面に出る権限が4つから2つになりました。「マイドライブは読めません」が、約束ではなく事実になりました。

代償もあります。プログラムが2つに分かれるので、共通の処理を2箇所に持つことになりました。それでも、こちらのほうが正しい判断だったと思っています。

利用者ごとに設定を保存する仕組み → 使えなかった

Apps Script には、利用者ごとにデータを保存する機能があります。便利なので使いたくなります。

「実行する人」の設定によって、意味が変わります。 「使う人として実行」なら利用者ごとに分かれますが、「自分（作った人）として実行」にすると全員が同じ領域を共有します。

つまり、利用者ごとの設定を保存したつもりが、全員で1つの設定を共有している状態になります。しかもエラーは出ません。

ここは実際に踏みました。認証方式を変えるときは、この機能の意味が変わることを必ず確認してください。

公開前チェックリスト

社員に配る前に、これを通してください。わたしが1つずつ踏んだものです。

資料をそろえる

• 資料の合計文字数を数えた（10万字を超えていないか）

• 資料の更新頻度を確認した（毎日書き換わるものが混ざっていないか）

• 「社員なら誰が見てもいい情報」だけになっている

• 個人の評価結果・給与額・面談記録を入れていない

• 「いま答えられないこと」の一覧を1ファイル作った

文字にする

• 表ごとに「何と何の掛け算か」を先に決めた

• 1行の書式を固定した（区切り記号を使った。自然な日本語にしていない）

• 変換プロンプトに「空欄も1行書く」を入れた

• 変換プロンプトに「出力行数を報告せよ」を入れた

• 出力行数が 項目数×等級数×段階数 と一致した

• 空欄の意味を人間が書き足した（「空欄＝対象外」など）

• 図で「これとこれは無関係」を明示した

• PDFから抽出した表を目で見た

• 目視で打った資料に「読み取れていない箇所がある」と書いた

実装

• 取り込みと利用を別処理に分けた

• 相談の種類ごとに読む資料を切り替えた

• キャッシュの鍵に資料の版を混ぜた

• キャッシュを分割して入れ、個数の印を最後に書いた

• 読めなかったファイルが1行残る作りになっている

• 利用者の権限でDriveを読む形になっていない

• 誰が何を聞いてAIが何と答えたかが記録されている

配る前

• 回答の下に「ここが違う」を押せる場所がある

• 押したあと、何が違ったかを書ける（書かずに送ってもよい）

• 「物足りない」と「壊れている」を利用者が区別できる説明を書いた

• 同じ質問セットで測って、配る前の点数を記録した

上の24項目のうち、わたしが最初に飛ばしたのは「出力行数を報告せよ」「読めなかったファイルが1行残る」「配る前の点数を記録」の3つです。3つとも、あとで事故になりました。

明日からやること（3時間）

1時間目：資料を数える

社内AIに読ませたい資料を、フォルダに集めて文字数を数えます。10万字以内なら、検索の仕組みは要りません。全部渡せます。超えていたら、まず「相談の種類」で分けて、種類ごとに10万字以内に収まるか見ます。

2時間目：いちばん厄介な表を1つだけ文字にする

全部やらないでください。1つだけです。上の手順1〜4を通して、変換プロンプトの検算が効くかを確かめます。ここで行数が合わなければ、資料の全部を疑う必要があります。

3時間目：質問を12問だけ書く

実際に来そうな質問を12問。きれいな日本語に直さず、来る言い方のまま書きます。そしてまだ何も作っていない状態で、その12問を手元のAIに投げて採点します。

これが基準線になります。

3時間目がいちばん大事です。 わたしは基準線を作らずに1ヶ月やって、良くなったのか分からないまま過ごしました。

付録

ここからは、コピーしてそのまま使えるものです。

特典1｜変換プロンプト4本セット

① 表を1行1文にする

以下は社内資料の表をCSVに書き出したものです。
これを1行1文の箇条書きに展開してください。

【書式】
{項目}／{区分}／{段階}：{記述}

【ルール】
- 元の記述を要約・言い換えしないこと。原文をそのまま使う
- 空欄のセルは「（記述なし）」と書く。飛ばさない
- 出力行数は、必ず (  ) 行になるはず
- 最後に、出力した行数を報告してください

【CSV】
（ここに貼る）

② 組織図・フロー図を文字にする

以下は組織図（またはフロー図）を説明したものです。
これをテキストの箇条書きにしてください。

【残すもの】
- 階層の上下（誰が誰の上か）
- どの役割がどの決裁権を持つか
- 社内での呼び方

【落とすもの】
- ボックスの位置・色・線の太さ
- この相談に出てこない部署

【必ず最後に足すこと】
図の中で離れて描かれている概念のうち、
「互いに無関係」なものがあれば「AとBは無関係」と明記してください。
テキストにすると近くに並ぶので、混同されます。

③ 崩れたPDFの表を直す

以下はPDFから抽出したテキストです。表の罫線が消えて崩れています。

【やること】
1. 元が何行何列の表だったかを推定し、最初に報告してください
2. 各行を復元し、{列名}：{値} の形にしてください
3. 復元に自信がない行は、行頭に「⚠」を付けてください
4. 復元できなかった箇所は、勝手に埋めず「（読み取れず）」と書いてください

推測で埋めるのが最悪です。読めなかったことが分かる形で残してください。

④ 表の「読み方」を書き足すための質問

以下の表を、AIに読ませる資料として使います。
この表について、「表の中には書かれていないが、
読む人が知らないと誤解する前提」を5つ挙げてください。

例：空欄が「情報がない」ではなく「対象外」を意味する、など。

挙げるだけでよいです。わたしが選んで、資料に書き足します。

特典2｜資料の先頭に付ける「出典ヘッダー」

すべての資料ファイルの1行目に、これを付けます。

出典：（原本のファイル名）
時点：（適用開始時期）
最新か：最新 / 旧版
更新責任者：（部署名）
作り方：原本のコピー / 目視で書き起こし / AI変換＋検算済み
未確認：⚠（読み取れていない箇所、他資料と食い違う箇所を書く）

「作り方」と「未確認」が効きます。 AIが答えられなかったとき、それが「AIの不調」か「資料に無い」かを即座に切り分けられます。そして半年後の自分が、目視で打った資料を正確な原本だと信じるのを防げます。

特典3｜「いま答えられないこと」ファイルのひな型

これがいちばん効いた1ファイルです。 知識ベースに何が無いかを、明示的に書きます。

# いま答えられないこと（未収録の資料一覧）

このファイルに書かれている話題は、社内資料が用意されていません。
聞かれた場合は、推測で答えず、以下の対応をしてください。

## 対応のルール
1. 「その資料は入っていません」と正直に伝える
2. 一般的な考え方を答えてよい。ただし「これは一般論であり、
   社内の基準ではありません」と先に明示する
3. 社内の評価軸・基準を根拠として使わない
4. 確認先（部署名）を必ず示す

## 資料が無い話題
- （話題）／確認先：（部署）
- （話題）／確認先：（部署）

## 部分的にしか無い話題
- （話題）／あるのは（範囲）まで。それ以外は確認先：（部署）

3の1行が肝です。 「答えるな」にすると利用者が困ります。「答えてよい。ただし社内の基準を根拠に使うな」 が正解でした。

特典4｜立ち上げチェックリスト

上の公開前チェックリストを、スプレッドシートに貼って `済` 列を足してください。配る前に1回、資料を足すたびに「文字にする」の9項目だけ、を回す形が回しやすいです。

社内AI 実践ノート

このシリーズは全文無料です。構築、取り込み、架空回答、評価、会社の見解、造語の順で読めます。

• 01 社内AIの構成と費用

• 02 資料の読み込みを点検

• 03 架空の制度を切り分ける

• 04 改善を数字で測る

• 05 会社の見解を断定させない

• 06 造語の出どころを点検

AIへの依頼を、日々の仕事で使うなら

管理職が無料で試せる依頼文で、小さな調査・比較から試せます。Excel・7種類の実務別指示文・完成サンプルが必要な方には、AI業務委任・検品キット（980円）を用意しています。