UI治具(UI Jig)で“Non‑ITが使える”ソフトウェアを数時間で製造する
生成AIでPythonコードは数分で作れるようになりました。しかし現場(事業計画・企画・運用)に渡すと、 「実行できない」「触って試せない」ために結局Excelへ戻ってしまいます。 AIBOD Factoryはこの断絶を、UI治具という標準工程で埋めます。 コアロジック(Python)に、テンプレ化されたUI治具(Tkinter)を被せ、PyInstallerでEXE出荷する。 その一連を “製造ライン” として固定し、Non‑ITが便利さを享受できる状態へ変換します。
“コードの速さ”を“現場の速さ”に変換する
Non‑ITの操作モデルはExcel型(数値を触る→即結果)です。 UI治具は、生成AIで作ったコアロジックを、その操作モデルに変換する「標準治具」です。
これはUIにも当てはまります。UI治具で「作り方」を固定し、出荷形態(EXE)まで閉じます。
1. アブストラクト(要約)
生成AIによりコード生成は高速化しましたが、現場のボトルネックは「使える形で届かない」点に残ります。 Non‑ITはCLI実行や環境構築に慣れておらず、数値を触って結果を見るExcel的な操作モデルが前提です。 AIBOD Factoryは、コアロジック(Python)にUI治具(Tkinterテンプレ)を取り付け、 PyInstallerでEXE出荷する標準工程を定義し、数時間で「現場が使えるソフト」を製造します。
- UIをコードで直書きせず、UI Schema(JSON)で定義して自動生成する
- UIとコアのI/Fを固定し、ロジック差し替えで横展開できる
- 配布摩擦を下げるため、Windows向けEXE出荷を標準にする
2. 背景:生成AIでコードは作れても現場は使えない
PythonはITに慣れた人にとって、最短距離で価値を生みます。一方、事業計画や現場改善の担当者に渡すと、 「どう実行するのか分からない」「数字を変えて試せない」ため、結果としてExcelに回帰します。
Non‑ITの現実
- 環境構築・依存関係の解決ができない
- コマンド実行が心理的ハードル
- 入力→結果の往復が遅い
- 結局、Excelで作り直す
本質:操作モデルの断絶
- IT:プロンプト→コード→検証→修正
- Non‑IT:数値を触る→即結果→比較→意思決定
- 同じ生成AIでも“使い方”が違う
3. 定義:UI治具(UI Jig)とは何か
UI治具とは、AIBOD Factoryにおける標準UI部品・標準レイアウト・標準I/Fの集合です。 UIを個別開発せず、治具として“作り方を固定”し、誰が作っても同品質・短時間で出荷できる状態を作ります。
UI治具の目的
- Excel脳(数値を触る→即結果)に合わせた操作モデルを提供する
- UIとコアを分離し、ロジック差し替えで別テーマへ横展開する
- EXE出荷を前提に、導入摩擦(インストール/環境構築)を最小化する
4. 標準仕様(v0.1):画面構成・入力治具・シナリオ
4.1 画面構成(標準レイアウト)
- 左:入力パネル(Parameter Panel)— セクション分割
- 右上:結果サマリ(KPI)— 損益分岐月/累積利益/顧客数/売上など
- 右下:グラフ(Charts)— 売上・費用、累積利益、顧客数の推移
- 下:操作バー(Action Bar)— 計算/初期値/保存/読込/CSV出力
4.2 入力治具(NumericField)ルール
- 単位を必ず表示(円、%、人、月)
- 初期値を必ず持つ
- 計算時にバリデーション(min/max)
- 入力・結果を同一画面に集約
- “新しいUI学習”を要求しない
- 「なんか見たことある」が最強
- 色演出より一貫性を優先
- 失敗しても落ちない(エラー表示)
4.3 シナリオ治具(ScenarioManager)
- 条件セットをJSONで保存/読込
- Non‑ITの「比較して考える」を支援
- CSV出力でExcel連携(戻り口)を確保
5. UI Schema(設計図)でUIを自動生成する
AIBOD Factoryの量産性を決めるのは、UIをコードで書かないことです。 入力項目・セクション・KPI・グラフ定義をUI Schema(JSON)で持ち、UIはそれを読み込んで自動生成します。
ここが固定されると、別テーマでも「schema差し替え」で即ツール化できます。
UI Schemaの最低要素
- sections: 入力セクションとフィールド定義(key/label/type/unit/default/min/max)
- kpi: KPI表示の定義
- charts: グラフの表示定義
(例)UI Schemaのイメージ
{
"title": "サブスク損益分岐シミュレータ",
"sections": [
{"name":"収益","fields":[
{"key":"monthly_price","label":"月額料金","type":"int","unit":"円/月","default":15000,"min":0,"step":500}
]}
],
"kpi":[{"key":"breakeven_month","label":"損益分岐月"}],
"charts":[{"type":"line","y":["monthly_revenue","monthly_cost"],"label":"月次 売上/費用"}]
}
6. 固定I/F:UIとコアの分離
UI治具はコアロジックを知らず、コアはUIを知りません。Factoryとして横展開するために、I/Fを固定します。
UI → Core
params: dict # key: string, value: number
例:monthly_price, churn_rate, simulation_months...
Core → UI
summary: dict # KPI
timeseries: DataFrame # month-by-month
UIはKPIと推移を描ければよい(形式は十分)
7. 出荷工程:EXE化(PyInstaller)
Non‑ITに届ける上で「環境構築が必要」は致命傷です。そこでUI治具ラインは、EXE出荷を標準工程とします。
標準(推奨)
- 最初は onedir(トラブルが少ない)
- ui_schema.json / scenarios/ を同階層に置き、差し替え可能にする
- ユーザーが触るのは scenarios/ のみ(運用治具)
pyinstaller --noconfirm --clean --onedir --windowed ^
--add-data "ui_schema.json;." ^
main.py
8. 事例:サブスク損益分岐シミュレータ
サブスク事業の損益分岐点を、月次でシミュレートするツールを対象に、UI治具ラインを適用しました。
- コア:Python(損益・顧客推移の計算)
- UI治具:Tkinterテンプレ(Schema駆動フォーム生成)
- 出荷:PyInstaller(Windows EXE)
- 現場体験:入力→計算→KPI/グラフ→シナリオ保存→CSV出力
“開発”ではなく“製造”として成立する、最小の成功パターン。
9. ロードマップ(v0.2以降)
v0.2:利用性強化(Non‑ITの満足度を上げる)
- グラフ凡例の日本語化(schemaでlabelMap)
- シナリオ比較(2〜3ケースの重ね描き)
- 重要パラメータのスライダー化(料金・解約率など)
v0.3:Factoryライン化(量産性を上げる)
- UI Schemaテンプレライブラリ化(見積・在庫・投資・工程能力など)
- 「要件→UI Schema→Core雛形」生成のプロンプトパターン確立
- 署名/バージョン表示/更新通知など運用治具
Non‑ITが便利さを享受するための“治具”を、Factoryの標準工程として固定する。