専門用語だらけの業務マニュアルや計算式を、現場の若手や非エンジニア部門にどう噛み砕いて伝えるか。この悩みを抱える業務システム担当者やSE向けに、社内向け「解説ツール」をどう設計・選定するかを整理します。
海外の開発コミュニティdev.toに投稿された「CrackIt」という個人プロジェクトが、この種のツール設計を考えるうえで分かりやすい材料になります。石油化学工学を学ぶ学生向けに、Ergun方程式（充填層内の圧力損失を求める式）のような難解な数式を、символ解説・計算例・電卓機能付きで段階的に見せるWebアプリです。UIにはGradio（Pythonで手早くWeb画面を作れるライブラリ）を使い、数値計算はPythonで確定的に行い、説明文の生成だけをGoogleの軽量オープンウェイトモデルGemma 3 4Bに任せる構成になっています。
この「計算はコードで固定し、説明はAIに任せる」という役割分担は、業務システムにおけるFAQボットやオンボーディング支援ツールを設計するときにも応用できる考え方です。以下、判断軸を整理します。
判断軸1: 計算・判定ロジックをAIに任せてよいか
CrackItの設計で最も重要なのは、圧力損失や流速といった数値計算を一切AIに行わせていない点です。
計算はすべてPythonの関数で確定的に実行し、AIモデルのGemma 3 4Bは解答のチェックや説明文の生成にしか使われていません。
業務システムでも同じ切り分けが必要です。たとえば在庫引当数や与信限度額の判定をLLM（大規模言語モデル）に直接計算させると、同じ入力でも出力がぶれる可能性があります。金額計算・在庫判定・承認フローのような「正解が一意に決まる処理」は既存のロジックやDBクエリに任せ、AIには「結果の説明」「問い合わせ対応の文面生成」だけを担わせる設計が安全です。
判断軸2: ホスティング環境と運用コストの見合い
CrackItはRender（PaaS型のホスティングサービス）上で稼働しており、個人開発レベルのスモールスタートを前提にしています。
社内向けツールの場合、まず「誰が」「何人くらい」「どの頻度で」使うかを見積もる必要があります。全社数千人が使う制度説明ボットと、特定部署の数名が使う手順書検索ツールでは、必要なインフラのグレードが全く違います。
小規模な部署内ツールであれば、CrackItのようにGradioで画面を作り、社内のコンテナ基盤やPaaSに載せるだけで十分なケースもあります。一方、全社展開や既存の社内システムとの連携が必要な場合は、認証基盤（SSO連携）やログ監査要件への対応が追加で発生する点を見込んでおく必要があります。
判断軸3: 既存ドキュメント・コードベースとの統合のしやすさ
CrackItは数式名を入力するか、教科書の写真をアップロードして画像認識モデルに公式を推定させる機能を持っています。
業務システムの現場では、すでに大量の設計書・運用手順書・FAQが社内Wikiやファイルサーバーに眠っているはずです。新しいツールを一から作るより、既存ドキュメントを読み込ませて回答させる「検索拡張生成」（RAG、関連文書を検索してからAIに回答させる手法）の方が投資対効果が高いケースが多いです。
CrackItのように「決まったテンプレート（公式名→解説→計算例）」に当てはめられる題材であれば自作UIが向きますが、ドキュメントの形式がバラバラな社内資料が対象なら、既存のRAG基盤やNotion AI・Confluence連携ツールの活用を先に検討した方が手戻りが少なくなります。
判断軸4: 保守する人がいなくなっても壊れないか
個人開発のツールは往々にして作った本人しかメンテナンスできません。業務システムとして長く使うなら、この属人化リスクを最初から見込む必要があります。
CrackItのコードはPythonの関数群とGradioのUI定義というシンプルな構成で、GitHubにオープンソースとして公開されています。業務システムに取り込む場合も、同じように「誰が読んでも処理の流れが追えるか」「AIモデルのバージョンが上がっても計算ロジックは影響を受けないか」を設計レビューの観点に入れておくと安心です。
選択肢の比較
社内向け解説・問い合わせ支援ツールを作る際によくある3つの方向性を整理します。
| 方式 | 向いている場面 | 注意点 |
|---|---|---|
| 自作UI+ルールベース計算(CrackIt型) | 対象が定型化できる専門分野、対象ユーザーが少人数 | テンプレート外の質問に弱い |
| 既存ドキュメントRAG連携 | 社内Wiki・手順書が大量にある、全社展開したい | 文書の整備状況に回答精度が左右される |
| チャットツール連携(Slack/Teams bot等) | 既存の問い合わせ文化がチャット中心 | 裏側のロジックは別途自前で用意が必要 |
ケース別の推奨
対象分野の計算式や判定ロジックが少数かつ固定的なら、CrackIt型の自作ミニアプリを選ぶのが手早く、Gradioのようなツールで数日〜数週間の工数に収まります。
社内に手順書やFAQが既に蓄積されており、検索性の低さが課題であれば、RAG型の仕組みを優先した方が投資効果が出やすいです。
問い合わせの窓口自体をチャットツールに一本化したい場合は、既存のSlack/Teamsのbot基盤に裏側のロジックを接続する形が、ユーザーの導線を変えずに済みます。
あえて見送るべき条件
一方で、次のような条件では無理にAI活用ツールを作らない方がよい場面もあります。
- 計算ロジックが頻繁に法改正や社内規定変更で変わる分野(保守コストがAIの説明生成部分より重くなる)
- 対象ユーザーが数名以下で、既存のExcelマクロや手順書で十分運用できている
- 誤った説明が重大な事故・損害につながる領域(医療・安全管理など)で、AIの説明文をそのまま現場に出せない
こうした条件に当てはまる場合は、ツール化よりも既存資料の整理やレビュー体制の強化を優先した方が合理的です。
まとめ
CrackItの設計から学べる最大のポイントは、計算ロジックと説明生成の役割分担です。
業務システムでAI活用を検討する際は、まず「数値計算・判定はAIに任せない」という原則を決め、そのうえで対象分野がテンプレート化できるか、既存ドキュメント資産がどれだけあるかを棚卸ししてみてください。
小さく作るならGradioのようなローコードUIフレームワークで試作し、効果が見えてから本番基盤への統合を検討するのが無理のない進め方です。