モデル概要
▾
AI-COCOMOは、COCOMO IIモデルを生成AI時代に拡張したコストモデルです。
総コストを以下の3層に分離して算出します。
C_total = C_human + C_AI + C_integration
・C_human（人的コスト）：COCOMO IIの工数算出にAI代替率αを適用
・C_AI（AIコスト） ：トークン消費量 + ライセンス費用
・C_integration ：AIとの協働レビュー・修正のオーバーヘッド
📄 モデルの詳細・理論的背景については、提案者 1_s_o の note 記事をご参照ください：
note.com/ichi_s_otsuki — AI-COCOMOコストモデルの提案 ↗
プリセット
▾
ファンクションポイント数
FP
IFPUG法で計測したシステムの機能規模。画面・帳票・ファイル・インターフェースなどの複雑度を数値化したもの。
言語（CF: FP→KLOC換算係数）
言語ごとの1FPあたりのソースコード行数（SLOC）。Python=15, TypeScript=20, Go=30, C#=46, Java=53, C=128。
新規開発比率
R_new
新規に開発するコードの割合（= 1 − 再利用率）。OSS・AI生成テンプレート・既存コードを再利用すると低下しコスト減。右に動かすほど新規開発が増えコスト増。
人件費単価（¥/時間）
LaborRate
人月÷160時間で算出。例：人月100万円＝6,250円/h。フリーランス上位層は12,500円/h程度。
為替レート（¥/$）
FX
AIのAPI料金はドル建てのため、円換算に使用します。
値が小さいほど良い（コスト削減）。0=Very High ～ 5=Very Low。▸ 評価基準をクリックで原典（SEC journal No.12）の評価基準を展開。
先例性
PREC
開発組織が、対象システムと同様のシステムを開発した経験と知識の量。前例が豊富なほどコミュニケーションのオーバーヘッドが減り、工数が下がる。
▸ 評価基準（クリックで展開）
| 評定（スライダー値） | SF値 | 評価基準 |
|---|---|---|
| 極めて高い (0) | 0.00 | 完全に馴染みあり |
| 非常に高い (1) | 1.24 | 大方馴染みあり |
| 高い (2) | 2.48 | だいたい馴染みあり |
| 中位 (3) | 3.72 | いくらか先例あり |
| 低い (4) | 4.96 | ほとんど先例無し |
| 非常に低い (5) | 6.20 | 全く先例無し |
開発柔軟性
FLEX
ソフトウェアの要件や外部インタフェース仕様に対する制約からの自由度。厳格な仕様準拠が求められるほどコストが増加し、ゴール指向で柔軟なほど下がる。
▸ 評価基準（クリックで展開）
| 評定（スライダー値） | SF値 | 評価基準 |
|---|---|---|
| 極めて高い (0) | 0.00 | 一般的な目標 |
| 非常に高い (1) | 1.01 | いくらか準拠 |
| 高い (2) | 2.03 | 一般的な準拠 |
| 中位 (3) | 3.04 | いくらか緩和 |
| 低い (4) | 4.05 | 場合により緩和 |
| 非常に低い (5) | 5.07 | 厳格に準拠 |
リスク管理度
RESL
リスク管理活動（プロトタイピング、技術検証、トレードオフ分析等）の実施度合い。アーキテクチャ上のリスクが事前に解消されているほど、工数が下がる。
▸ 評価基準（クリックで展開）
| 評定（スライダー値） | SF値 | 評価基準 |
|---|---|---|
| 極めて高い (0) | 0.00 | 完全に行われている（100%） |
| 非常に高い (1) | 1.41 | ほとんど行われている（90%） |
| 高い (2) | 2.83 | だいたい行われている（75%） |
| 中位 (3) | 4.24 | しばしば行われている（60%） |
| 低い (4) | 5.65 | いくらか行われている（40%） |
| 非常に低い (5) | 7.07 | ほとんど行われていない（20%） |
チーム結束度
TEAM
ユーザ・開発者・発注者・保守担当者など利害関係者間の協力と開発ビジョン共有の程度。結束度が高いほど工数が下がる。
▸ 評価基準（クリックで展開）
| 評定（スライダー値） | SF値 | 評価基準 |
|---|---|---|
| 極めて高い (0) | 0.00 | シームレスな相互作用 |
| 非常に高い (1) | 1.10 | 非常に協力的 |
| 高い (2) | 2.19 | 大方協力的 |
| 中位 (3) | 3.29 | 基本的に協力的な相互作用 |
| 低い (4) | 4.38 | いくらか困難な相互作用 |
| 非常に低い (5) | 5.48 | 非常に困難な相互作用 |
プロセス成熟度
PMAT
組織のソフトウェア開発プロセスの成熟度。SEI CMMのレベルに対応。AI支援開発では、CI/CD整備・テスト自動化・AI生成コードの品質保証プロセスの有無として解釈する。
▸ 評価基準（クリックで展開）
| 評定（スライダー値） | SF値 | 評価基準（SEI CMM） |
|---|---|---|
| 極めて高い (0) | 0.00 | レベル5（最適化） |
| 非常に高い (1) | 1.56 | レベル4（定量的管理） |
| 高い (2) | 3.12 | レベル3（定義済み） |
| 中位 (3) | 4.68 | レベル2（管理） |
| 低い (4) | 6.24 | レベル1 上位 |
| 非常に低い (5) | 7.80 | レベル1 下位 |
0.50〜1.50。1.0が基準。能力系EMは低い値ほどコスト減。▸ 評価基準をクリックで原典の数値を展開。
要求される信頼性
RELY
意図した機能を実行し続けることへの要求と、障害発生時の影響の大きさ。信頼性要求が高いほど、テスト・検証工数が増加する。
▸ 評価基準（クリックで展開）
| 評定 | EM値 | 評価基準 |
|---|---|---|
| 非常に低い (VL) | 0.82 | 若干の不便 |
| 低い (L) | 0.92 | 簡単に回復可能な損失 |
| 中位 (N) | 1.00 | 回復可能な中くらいの損失 |
| 高い (H) | 1.10 | 財政上の大きな損失 |
| 非常に高い (VH) | 1.26 | 人命に影響を及ぼす |
データ複雑度
DATA
テスト用データベースのサイズとプログラムサイズの比率（D/P比）。大規模なテストデータの準備・管理が必要なほど工数が増加する。
▸ 評価基準（クリックで展開）
| 評定 | EM値 | D/P比（テストDB÷SLOC） |
|---|---|---|
| 低い (L) | 0.90 | D/P < 10 |
| 中位 (N) | 1.00 | 10 ≦ D/P < 100 |
| 高い (H) | 1.14 | 100 ≦ D/P < 1000 |
| 非常に高い (VH) | 1.28 | D/P ≧ 1000 |
製品複雑度
CPLX
制御フロー、数値計算、デバイス依存処理、データ管理、ユーザインタフェースの5側面から見たソフトウェアの複雑さの総合評価。
▸ 評価基準（クリックで展開）
| 評定 | EM値 | 評価基準 |
|---|---|---|
| 非常に低い (VL) | 0.73 | 単純 |
| 低い (L) | 0.87 | いくらか複雑 |
| 中位 (N) | 1.00 | 適度に複雑 |
| 高い (H) | 1.17 | 複雑 |
| 非常に高い (VH) | 1.34 | かなり複雑 |
| 極めて高い (XH) | 1.74 | 極めて複雑 |
要求される再利用性
RUSE
開発するソフトウェアを将来のプロジェクトで再利用するために追加で必要な工数。再利用の範囲が広いほど、汎用性確保のためのコストが上がる。
▸ 評価基準（クリックで展開）
| 評定 | EM値 | 評価基準 |
|---|---|---|
| 低い (L) | 0.95 | 再利用を意図しない |
| 中位 (N) | 1.00 | プロジェクト内で再利用 |
| 高い (H) | 1.07 | 複数プロジェクト間で再利用 |
| 非常に高い (VH) | 1.15 | プロダクトラインで再利用 |
| 極めて高い (XH) | 1.24 | 複数プロダクトライン間で再利用 |
プラットフォーム制約
PLAT
メモリ・性能などの実行環境制約。クラウド・サーバーレス環境では低め。組み込みや高性能リアルタイム要件がある場合は高め。
人員能力（分析・設計）
PCAP
開発者の分析・設計・実装能力、コミュニケーション能力、協調性。同職種の一般的な人材母集団に対するパーセンタイルで評価。能力が高いほどEM値が小さくなりコスト減。
▸ 評価基準（クリックで展開）
| 評定 | EM値 | 評価基準（パーセンタイル） |
|---|---|---|
| 非常に低い (VL) | 1.34 | 下位より15% |
| 低い (L) | 1.15 | 下位より35% |
| 中位 (N) | 1.00 | 下位より55% |
| 高い (H) | 0.88 | 下位より75% |
| 非常に高い (VH) | 0.76 | 下位より90% |
人員経験（アプリ分野）
PEXP
チームの、開発対象と類似のアプリケーション分野での経験年数。豊富な経験でコスト減。
▸ 評価基準（クリックで展開）
| 評定 | EM値 | 経験年数 |
|---|---|---|
| 非常に低い (VL) | 1.22 | 2ヵ月以下 |
| 低い (L) | 1.10 | 6ヵ月以下 |
| 中位 (N) | 1.00 | 1年 |
| 高い (H) | 0.88 | 3年 |
| 非常に高い (VH) | 0.81 | 6年 |
AI活用習熟度 ✨
AILX
【AI-COCOMO拡張】プロンプト設計・AIツール運用力。高習熟（低EM値）でコスト削減。また統合コストの算出にも使用。原典のLTEX（言語・ツール経験）に相当するAI時代の新設パラメータ。
▸ 評価基準（クリックで展開）
| 評定 | EM値 | 評価基準 |
|---|---|---|
| 非常に低い (VL) | 1.20 | AIツール初使用。プロンプト設計の知識なし |
| 低い (L) | 1.09 | 基本的なChat利用のみ（6ヵ月未満） |
| 中位 (N) | 1.00 | コード生成・デバッグに日常的に活用（1年程度） |
| 高い (H) | 0.91 | プロンプトエンジニアリング熟練。RAG・エージェント経験あり（3年程度） |
| 非常に高い (VH) | 0.84 | AIワークフロー設計・最適化の専門家（6年以上相当） |
ツール成熟度
TOOL
CI/CD・AI統合開発環境の整備度。整備されているほどコスト減。
スケジュール圧縮
SCED
COCOMOが算出する最適開発期間に対する、要求される開発期間の割合。スケジュールを短縮するほど工数が増加する。ただし延長しても工数は減らない（パーキンソンの法則）。
▸ 評価基準（クリックで展開）
| 評定 | EM値 | 評価基準（最適期間比） |
|---|---|---|
| 非常に低い (VL) | 1.43 | 標準の75%（大幅短縮） |
| 低い (L) | 1.14 | 標準の85% |
| 中位 (N) | 1.00 | 標準の100% |
| 高い (H) | 1.00 | 標準の130%（延長しても減らない） |
| 非常に高い (VH) | 1.00 | 標準の160%（同上） |
COCOMO II → AI-COCOMO パラメータ対比
| COCOMO IIパラメータ | AI-COCOMOでの扱い | 理由 |
|---|---|---|
| TIME（実行時間制約） | 廃止 | クラウド・サーバーレス化により実務上の制約でなくなった |
| STOR（メモリ制約） | 廃止 | 同上 |
| PVOL（プラットフォーム安定性） | 廃止 | クラウド環境では基盤が抽象化されている |
| LTEX（言語・ツール経験） | 廃止 → AILX ✨ | AI支援により学習曲線が平坦化。AILX（AI活用習熟度）に置換 |
| SITE（複数拠点） | 廃止 | リモートワーク標準化により補正の必要性低下 |
| — | 新設：α（AI代替率） | 人間工数のうちAIで代替される割合（AI設定タブ） |
| — | 新設：γ（イテレーション係数） | FP当たりのAIトークン消費乗数（AI設定タブ） |
人的担当率
1-α
人間が担当する作業の割合（= 1 − AI代替率α）。100%がAI無しの純人的開発。低いほどAI活用が高くコスト削減。右に動かすほど人的作業が増えコスト増。
▸ α（AI代替率）の評価基準（クリックで展開）
| AI代替率 α | 人的担当率 | 評価基準 |
|---|---|---|
| 0.10〜0.20 | 80〜90% | AIはコード補完のみ。設計・実装は人間が担当 |
| 0.20〜0.40 | 60〜80% | AIが部分的にコード生成。人間が大部分を担当 |
| 0.40〜0.60 | 40〜60% | AIが設計相談・コード生成・テスト生成を担当。人間の判断が多く残る |
| 0.60〜0.80 | 20〜40% | AIがコード生成・デバッグ・テストの大部分を担当。人間は方針決定と最終レビュー |
| 0.80〜0.95 | 5〜20% | AIがほぼ全工程を担当。人間は要件定義とAI出力のレビューのみ（α≈0.82: chidouka-lab実績） |
※ α=1.0（完全代替）は非現実的。要件解釈・ビジネス判断・AI出力の品質保証は常に人間の仕事として残る。
出力トークン単価
P_out
AIモデルの出力トークン単価（$/MTok）。Claude Sonnet 4系=15程度、GPT-4o=10程度。
入力トークン単価
P_in
AIモデルの入力トークン単価（$/MTok）。通常は出力の1/4程度。
イテレーション係数
γ
AI出力の修正・再生成の往復回数（TI：トークン強度に相当）。高いほどトークン消費増。典型値は2〜3。
▸ TI（トークン強度）との対応（クリックで展開）
| γ値 | 評価基準 | 典型的なタスク |
|---|---|---|
| 1.0〜1.5 | 低い往復回数 | 定型的なCRUD画面、単純なフォーム処理 |
| 2.0〜3.0 | 標準的な往復回数 | API統合、中程度のビジネスロジック（推奨初期値） |
| 3.0〜4.0 | 高い往復回数 | 複雑なアルゴリズム、対話的デバッグが頻繁な機能 |
| 4.0〜5.0 | 非常に高い往復回数 | AI連携機能、大量コンテキスト参照、長大なシステムプロンプト |
AIライセンス費（¥/月）
L_AI_m
AIツールの月額ライセンス費。Claude Pro=¥3,000、Copilot=¥2,200、複数ツール併用で¥10,000以上も。
AIツール利用メンバー数
M
AIライセンスの課金対象となるメンバー数。人数課金プラン（Claude Pro・Copilot等）は実人数を設定。企業包括契約・Enterprise APIの場合は1のまま（L_AI_mに月額総費用を入力）。
プロジェクト期間
Months
ライセンス費の累計算出用。開発期間（月）を設定してください。
統合OH率
δ
AIとの協働によるレビュー・修正オーバーヘッド割合。AIを深く使うほど高くなる傾向。
推定コスト
TOTAL COST
—
調整規模
—
基本工数
—
AI無し比 節約率
—
FP規模感度グラフ
横軸：FP数 ／ 縦軸：総コスト ● 現在値
計算過程
▾