Claude Codeでソフトウェアの資産計上と工数を仕分ける — 研究開発費との線引き
自社利用ソフトウェアの制作工数を、gitログとチケットから資産計上の候補・研究開発費・保守に仕分ける手順です。Claude Codeに任せる分類と、経理が決める判断の境目を示します。
自社で使うソフトウェアの制作費は、「将来の収益獲得又は費用削減が確実」と認められた時点から資産に計上し、確実と認められない分は費用にします。この線引きに必要な元表、つまり「どの工数が、どの区分に落ちるか」の一覧は、gitログとチケットのエクスポートをClaude Codeに読ませると短時間で作れます。ただし資産計上の可否そのものは、経理が証憑を見て決める判断です。Claude Codeに任せるのは、チケット1件ずつの区分案と根拠の抜き出しまでにとどめます。
資産計上と費用処理の線引きは「確実性」と「期間」で決まる
仕分けの基準は、公認会計士協会の実務指針(研究開発費及びソフトウェアの会計処理に関する実務指針)にあります。11項は、自社利用ソフトウェアについて、将来の収益獲得又は費用削減が確実と認められる場合は無形固定資産に計上し、確実と認められない場合、または確実かどうか不明な場合は費用処理すると定めています。
資産計上される一般的な例として、実務指針は次の3つを挙げています。
- 通信ソフトウェアなどを使い、契約に基づいて第三者へ情報処理サービスを提供し、対価を得る場合
- 自社で制作し、当初の使途で継続利用することで、業務を効率的または効果的に遂行できると明確に認められる場合(間接人員の削減による人件費の削減効果が確実に見込まれる場合など)
- 市販のソフトウェアを購入し、予定した使途で継続利用する場合
2つ目の例には続きがあります。「ソフトウェア制作の意思決定の段階から制作の意図・効果が明確になっている場合」とされています。企画の段階で効果が語られていない制作は、確実性の説明が難しくなります。
もう1つの軸が期間です。12項は、資産計上の開始時点を「確実であると認められる状況になった時点」とし、それを立証できる証憑に基づいて決めるとしています。証憑の例は、制作予算が承認された社内稟議書と、制作番号を記入した管理台帳です。終了時点は13項で、制作作業が実質的に完了したと認められる時点とされ、証憑の例はソフトウェア作業完了報告書や最終テスト報告書です。
一方、研究開発費は、研究開発費等に係る会計基準でこう定義されます。
- 研究: 新しい知識の発見を目的とした計画的な調査及び探究
- 開発: 新しい製品・サービス・生産方法の計画や設計、または既存の製品等を著しく改良するための計画や設計として、研究の成果などを具体化すること
研究開発費はすべて発生時に費用処理します。ソフトウェア制作費のうち研究開発に当たる部分も同じです。
ここから、工数の仕分けに使える軸が3つ取れます。
| 軸 | 見るもの | 判断の根拠 |
|---|---|---|
| 期間 | 見るもの稟議承認日より前か後か、完了報告日より後か | 判断の根拠12項・13項の証憑 |
| 性質 | 見るもの新しい仕組みの設計か、既存機能の維持か | 判断の根拠研究開発の定義、実務指針15項 |
| 確実性 | 見るもの効果が稟議に書かれているか | 判断の根拠11項 |
期間は日付の比較で決まるので、機械的に処理できます。性質は文章の読解が要り、Claude Codeの出番です。確実性だけは経理の判断として残ります。
元表に必要な3つの入力
工数の按分には、次の3つが必要です。
- 作業の記録: gitログ、またはチケットのエクスポート(ID、題名、ラベル、完了日)
- 工数の実績: 勤怠・工数管理から出した「チケットID、担当者、時間」の表
- プロジェクトの期間表: 制作番号ごとの、稟議承認日(資産計上の開始)と完了報告日(終了)
gitログに時間は載っていません。時間はあくまで2の実績から取ります。Claude Codeにコミット数や差分行数から時間を推定させると、経理が検証できない数字が混ざります。Claude Codeが担うのは、各チケットが「何の作業か」の分類だけです。
git log --since=2026-04-01 --until=2026-09-30 --no-merges \
--pretty=format:'%h%x09%ad%x09%s' --date=short > git-log.tsvチケットはCSVでエクスポートします。列は ticket_id,title,labels,closed_at,description を想定します。コミットメッセージにチケットIDが入っていれば、gitログとチケットはIDで結べます。入っていない運用だと、コミット単位の按分は精度が落ちるので、チケット単位で集計するほうが安全です。
区分のルールをファイルに書いておく
分類は、毎回プロンプトで説明するより、判定ルールをファイルにしておくほうがぶれません。経理と合意した区分を rules.md に置きます。例えば次のような形です(区分名は各社の運用に合わせて変えてください)。
# 工数区分ルール
- capitalize: 稟議承認済みの制作番号に属し、新機能の実装・結合テスト・
移行設計など、完成までの制作作業
- research: 新しい手法の調査、技術検証、試作で、稟議の対象外のもの
- maintenance: バグ取り、障害対応、運用・保守、軽微な表示修正
- training_conversion: データ移行の変換作業、利用者向けトレーニング
- unclear: 題名と説明から判断できないもの。推測で埋めず unclear にする
# 注意
- 題名・説明に書かれていない事実を補わない
- 判断の根拠は、題名か説明からの引用で示すunclear を用意するのが要点です。選択肢が4つしかないと、判断がつかないチケットも無理にどれかへ入ります。逃げ道を作っておけば、経理が見るべき行が自然に絞られます。
実務指針は、データのコンバート費用とトレーニング費用を、発生した事業年度の費用とすると定めています(16項)。そのため、この2つは capitalize とは別の区分にしておくと、後で集計が混ざりません。
Claude Codeを非対話で回して、区分案をJSONで受け取る
非対話モードは claude -p です。標準入力のデータを読ませられ、--output-format json と --json-schema を組み合わせると、スキーマに沿った出力が structured_output フィールドに入ります。スクリプトやCIで使うときは --bare を付けると、手元のフックやMCPサーバー、CLAUDE.mdを読み込まないので、どの端末でも同じ条件で動きます。--bare はサブスクリプションのログインを使わないため、ANTHROPIC_API_KEY の設定が前提です。
まず出力の形を schema.json に書きます。
{
"type": "object",
"properties": {
"items": {
"type": "array",
"items": {
"type": "object",
"properties": {
"ticket_id": {"type": "string"},
"category": {
"type": "string",
"enum": ["capitalize", "research", "maintenance",
"training_conversion", "unclear"]
},
"evidence": {"type": "string"}
},
"required": ["ticket_id", "category", "evidence"]
}
}
},
"required": ["items"]
}実行は次のとおりです。ルールとチケットを標準入力にまとめて流し込みます。
{ cat rules.md; echo; echo '--- tickets.csv ---'; cat tickets.csv; } | \
claude --bare -p "rules.md の区分ルールに従い、全チケットを分類して" \
--output-format json --json-schema "$(cat schema.json)" > result.json入力が多いときは、月ごと、または制作番号ごとにファイルを分けて回します。1回の実行が重くなるうえ、失敗したときのやり直しも小さく済みます。
--output-format json の応答には total_cost_usd などのコスト情報が含まれます。ただし、これはクライアント側の概算で、実際の請求額と異なる場合があります。
形の例として、result.json の structured_output は次のような構造になります(数値や文面はすべて架空です)。
{"items": [
{"ticket_id": "PRJ-142", "category": "capitalize",
"evidence": "題名「請求データ連携の新規画面」"},
{"ticket_id": "PRJ-171", "category": "maintenance",
"evidence": "説明「本番で発生した二重登録の障害対応」"},
{"ticket_id": "PRJ-190", "category": "unclear",
"evidence": "題名「対応」のみで説明なし"}
]}実際の内容は、チケットの書き方で大きく変わります。区分案はそのまま採用せず、次の手順で検証できる形にします。
工数を結合して集計するのは、Claude Codeに任せない
按分の計算は、分類結果と工数実績の結合なので、決まった手順で動くスクリプトに任せます。LLMに足し算をさせると、毎回結果が揺れるうえ、経理が再現できません。Claude Codeに依頼するなら、このスクリプトを書かせる段階までです。
import csv, json
cat = {i["ticket_id"]: i for i in
json.load(open("result.json"))["structured_output"]["items"]}
period = {} # 制作番号ごとの (開始日, 終了日)。period.csv から読む(このコードでは未使用。期間判定は下で説明)
rows = {}
for r in csv.DictReader(open("timesheet.csv")):
c = cat.get(r["ticket_id"], {"category": "unclear"})["category"]
rows[c] = rows.get(c, 0) + float(r["hours"])
for c, h in sorted(rows.items()):
print(c, h)実際には、ここに期間の判定を加えます。稟議承認日より前の工数は、区分が capitalize でも費用側に回します。12項は、資産計上の開始時点を、将来の収益獲得または費用削減が確実と認められる状況になった時点とし、制作予算が承認された稟議書や制作番号入りの管理台帳といった証憑で決めるとしています。したがって、その開始日より前の工数は費用側に置くのが自然な扱いです。完了報告日より後の作業も、13項の終了時点を過ぎているので資産計上期間の外です。
出力する元表は、1行を1チケットとし、列を次のようにすると経理が追いやすくなります。
| 列 | 内容 |
|---|---|
| ticket_id | 内容チケットID |
| category | 内容Claude Codeの区分案 |
| evidence | 内容区分の根拠(題名・説明の引用) |
| in_period | 内容資産計上期間内か(日付比較の結果) |
| hours | 内容工数実績の合計 |
| final_category | 内容経理が確定した区分(空欄で渡す) |
最終列を空欄で渡すのがポイントです。区分案と確定値が別の列にあれば、後から「どこを人が直したか」が残ります。
経理が検証する点
元表を受け取った経理が見るべき項目を、実務指針と国税庁の資料から挙げます。
| 検証項目 | 見ること | 根拠 |
|---|---|---|
| 確実性 | 見ること稟議に、効果(人件費の削減、業務統合など)が書かれているか | 根拠実務指針11項 |
| 開始日・終了日 | 見ること日付が稟議書・完了報告書と一致するか | 根拠実務指針12項・13項 |
| 既存ソフトの大幅な仕様変更 | 見ること費用になる場合は購入ソフトの価額も含めて費用処理 | 根拠実務指針15項 |
| 導入時の周辺費用 | 見ることデータ変換・トレーニング費用が資産に混ざっていないか | 根拠実務指針16項 |
| 税務上の取扱い | 見ること会計で費用にした研究開発費の扱いが、税務でも同じか | 根拠国税庁タックスアンサー No.5461 |
注意したいのは、税務と会計で範囲が違うことです。国税庁のタックスアンサーによると、ソフトウエアの取得価額に算入しないことができる費用として、仕損じが明らかな製作費用、研究開発費の額、少額の間接費(製作原価のおおむね3%以内)が例示されています。研究開発費は、自社利用のソフトウエアの場合、その利用により将来の収益獲得または費用削減にならないことが明らかなものに限られます。会計上は「確実と認められない」だけで費用にできても、税務上は「ならないことが明らか」でなければ、取得価額に算入しない扱いにならない場合があります。会計の元表を作ったあと、税務調整の要否は別に確認が要ります。
耐用年数も別の論点です。同ページによれば、ソフトウエアの耐用年数は、複写して販売するための原本と開発研究用のものが3年、それ以外が5年です。自社利用の業務システムは、通常は後者になります。固定資産としての償却の検算は固定資産台帳と減価償却費の整合チェックの手順で行えます。
つまずきやすい点
コミットメッセージだけで分類しない
「fix」「update」だけの履歴からは、保守なのか新機能の仕上げなのか判断できません。チケットの説明に当たれない行は、unclear で経理に渡すほうが正確です。分類の精度を上げたければ、題名の書き方を開発チーム側で揃えるほうが効きます。
1チケットに複数の性質が混ざる
新機能の実装中に見つかった既存バグの修正など、1件に2種類の作業が入っていることがあります。工数もチケット単位で記録されていると、按分できません。チケットを分けるか、担当者に内訳を申告してもらうか、運用で決めておく必要があります。
分類結果を正としない
同じ入力でも、実行のたびに区分案が変わることがあります。確定した final_category を保存し、次回以降の実行ではその確定値を優先する運用にすると、期をまたいで結果がぶれません。
権限は最小にする
非対話で動かすときは、--allowedTools で使えるツールを絞ります。分類だけなら Read で足ります。gitログの取得など、シェルを使う作業は Bash(git log *) のように前方一致で限定できます。
まとめ
工数の仕分けは、期間は日付で、性質はClaude Codeの分類案で、確実性は経理の判断で、と役割を分けると回ります。Claude Codeの出力は「区分案と根拠の引用」まで、集計はスクリプト、確定は経理、という流れにしておけば、期末の監査で「この数字はどこから来たか」と問われても、元表の根拠列と稟議書にたどり着けます。
工数集計そのものをExcelで進める場合は、士業事務所の工数集計の手順が参考になります。claude -p の権限やCIでの扱いは、claude -pオプションとはで詳しく整理しています。