kintoneの出張申請｜3アプリ構成と設計

kintoneで出張申請を作る方法を調べると、サイボウズのサンプルアプリを入れてプロセス管理を設定する、という説明に行き着きます。それは正しいのですが、アプリをいくつに分けるかという最初の判断について書いたものがほとんどありません。

ここを間違えると後から効いてきます。出張申請は、稟議や経費申請とは構造が違うからです。本記事では、まずその違いを確定させ、そこからアプリ構成を決める順序で整理します。

プロセス管理そのものの仕組みはkintoneのプロセス管理とは？を、設定手順はプロセス管理を設定する方法を参照してください。本記事は出張という業務に固有の設計に絞ります。

この記事の要点

• 出張申請が他の申請と違うのは3点。承認と支出の間に「手配」が挟まる／申請時点で金額が確定しない／1件の出張から4種類の支出が出る。
• アプリ構成は3パターン。件数と精算の粒度で決まる。1アプリ統合は月20件が限界の目安。
• 申請時の金額は見積であって確定額ではない。差額の許容範囲を先に決めておかないと、承認のやり直しが日常になる。
• 日当の自動計算と定期区間の控除は、標準の計算フィールドで組める。ただし規程を数式に落とす前に、規程側の曖昧さを潰す必要がある。
• 標準機能の限界のうち、出張で最も効くのは承認リードタイムが運賃に直結すること。これはプロセス管理の設定では解決しない。

出張申請は他の申請と何が違うのか

構成を決める前に、ここを確定させます。3点あります。

1. 承認と支出の間に「手配」が挟まる

備品購入の稟議なら、承認の次は発注です。経費申請なら、支出は既に終わっています。出張は、承認のあとに「切符とホテルを押さえる」という工程が入ります。

この工程は誰かがやらなければなりません。出張者本人がやるのか、総務が代行するのか、外部のサービスを使うのか。ここを決めないままアプリを作ると、承認済みで手配待ちのレコードが溜まります。 ステータスとしては「承認済み」なので、止まっていることが誰にも見えません。

2. 申請時点で金額が確定しない

これが出張の最大の特徴です。申請書に書く運賃と宿泊費は見積です。実際にいくらになるかは、予約した瞬間に決まります。

出張費の相場｜規程額と実勢価格の差で整理したとおり、羽田〜福岡は事前購入と直前手配で往復約14,000円の差が出ます。1泊2日の総額約5万円に対して2割超です。

つまり申請額と実額は必ずずれます。 このずれをどう扱うかを設計しておかないと、「承認額と違うので再申請してください」という差し戻しが日常になります。

3. 1件の出張から4種類の支出が出る

交通費・宿泊費・日当・現地交通費。証憑の出方がそれぞれ違います。

費目	証憑	特徴
交通費（鉄道）	領収書なしが多い	経路と金額を自己申告する
交通費（航空）	領収書あり	予約時に確定する
宿泊費	領収書あり	上限との比較が必要
日当	証憑なし	規程から計算する
現地交通費	領収書あり／なし混在	件数が多く単価が小さい

申請の単位（出張1件）と、精算の単位（費目ごとの明細）が一致しません。 ここがアプリ構成を決める要因になります。

アプリ構成の3パターン

サイボウズのサンプルアプリには「出張申請」「旅費精算申請」「交通費申請」が別々に用意されています。これをどう組み合わせるかが設計です。

	1アプリ統合	2アプリ	3アプリ
構成	出張申請＝精算	出張申請＋旅費精算	出張申請＋手配＋旅費精算
精算の入力	同じレコードに追記	申請をルックアップして起票	同上
向く件数	月20件まで	月20〜200件	月200件以上／手配を代行する組織
承認回数	1回（事前のみ）	2回（事前・精算）	2〜3回
未手配の可視化	できない	できない	できる
集計のしやすさ	○	◎	◎
設定・保守の重さ	軽い	中	重い

1アプリ統合：小規模なら十分

出張申請のレコードに、帰着後に実額を追記して精算まで済ませます。レコードが1件で完結するので、申請と精算の紐付けを考えなくてよいのが利点です。

問題は2つあります。ひとつは、申請時点では空欄の項目（実額・領収書）がフォームに並ぶこと。申請者が何を埋めるべきか分かりにくくなります。もうひとつは、プロセス管理のステータスが一本道になること。「承認済み」から「精算待ち」「精算承認済み」まで同じ流れに乗せるため、ステータスが増えて読みにくくなります。

月20件を超えたあたりから、一覧画面で「いま何が止まっているのか」が追えなくなります。

2アプリ：多くの会社の現実解

出張申請アプリと旅費精算アプリを分け、精算側で申請番号をルックアップします。申請と精算でフォームの項目が独立するので、どちらも読みやすくなります。

設計の要点はルックアップのキーです。出張申請の自動採番フィールドを精算側から引くのが基本形で、これで1件の出張に複数の精算（交通費と宿泊費を別レコードにする場合）を紐付けられます。

注意点は、申請せずに精算だけ起票できてしまうこと。 ルックアップを必須にすれば防げますが、必須にすると「急な出張で事後申請」のケースが通らなくなります。事後申請を許すなら、事後フラグを立てて件数を数える設計にしてください。件数が増えているなら、それは運用ではなく承認速度の問題です。

3アプリ：手配を工程として持つ

出張申請と旅費精算の間に「手配」アプリを挟みます。承認済みで手配が終わっていないレコードが可視化されるのが、この構成の唯一かつ最大の利点です。

総務が手配を代行する組織では、これがないと手配の担当者が承認通知のメールを頼りに作業することになります。誰の分がまだ手配できていないかが一覧で見えるかどうかが、この構成を入れるかの判断基準です。

代わりに、アプリ間のルックアップが2段になり、保守が重くなります。件数が少ないのに3アプリにすると、運用されないアプリが1つできるだけです。

設計で決めておく4つのこと

1. 申請額と実額のずれの許容範囲

前述のとおり、ずれは必ず出ます。設計の選択肢は3つです。

• 全件を精算時に再承認する — 正確だが、承認者の負荷が2倍になる
• 一定額・一定率までは自動で通す — 実務的。「申請額の±10%または5,000円以内」のような条件をプロセス管理の実行条件に書く
• 上振れのみ承認、下振れは自動 — 統制上はこれで足りることが多い

推奨は2番目です。 許容範囲を規程側に明記し、その数値をプロセス管理の条件式に落とします。範囲を決めずに運用を始めると、承認者が毎回判断することになり、結果として全件が形式承認になります。

2. 日当の計算ルール

日当は計算フィールドで自動化できますが、規程が曖昧なままだと数式に落とせません。 先に決めるべきは次の4点です。

• 出発・帰着の時刻で日数を数えるのか、日付で数えるのか
• 日帰りと宿泊で単価を分けるのか
• 距離や所要時間の要件を置くのか（「片道50km以上」など）
• 食事が提供された場合に控除するのか

3番目と4番目を決めていない規程が多く、ここが出張の不正10類型で挙げた日当の二重取りの温床になります。決め方は出張規程の作り方を参照してください。

3. 定期区間の控除

通勤定期の区間を交通費から除く処理です。ユーザー情報に定期区間を持たせて、申請時に自動で差し引くのが理想ですが、標準機能だけでは区間の一致判定ができません。

現実的な設計は2つです。

• 自己申告のチェックボックス（「定期区間を含まない」を必須にする）— 抑止力はあるが検証はできない
• 乗換案内系の連携サービスを使う — 「K-Apps 旅費交通費精算 with 乗換案内Biz」のように、経路探索と定期区間の除外に対応した連携サービスがあります

件数が多いなら後者です。単価は小さいが件数が多い費目なので、手作業の確認は合いません。

4. 立替と法人決済の混在

同じ出張の中で、航空券は法人カード、現地交通費は立替、というケースが普通に起きます。明細ごとに支払手段のフィールドを持たせて、立替分だけを精算金額に合計する設計が必要です。

これを持たないと、法人カードで払ったものを立替としても申請する二重請求を検知できません。この論点はkintoneの個人立替精算はなぜ解消しないのかで扱っています。

プロセス管理の設計

出張申請で使う分岐は、実質2種類です。

金額による分岐 — 総額が一定額を超えたら承認者を追加する。数値条件式の書き方には癖があるので、設定手順の記事を確認してください。

出張種別による分岐 — 日帰り／国内宿泊／海外で承認ルートを変える。海外は渡航先の安全情報確認や保険加入の確認が入るため、別ルートにするのが普通です。

ステータス名は状態で書きます。「上長承認」ではなく「上長承認待ち」です。「上長承認」だと、承認待ちなのか承認済みなのかが一覧から読み取れません。

そして**「手配待ち」というステータスを置くかどうか**が、前述の3アプリ構成にするかの判断と直結します。1アプリ・2アプリ構成でも、承認済みの中に手配待ちを表すステータスを1つ挟むだけで、止まっているレコードは見えるようになります。

標準機能で残るもの

kintone承認プラグイン比較で整理した標準機能の5つの穴は、出張申請でもそのまま出ます。一括承認ができない、代理承認の専用機能がない、既読が分からない、ライセンスがないと承認できない、条件分岐が増えると保守が難しい——この5つです。

ただし、出張に固有でいちばん効く限界は別にあります。

承認リードタイムが、そのまま運賃になる

事前購入運賃には期限があります。申請から承認までに数日かかると、その間に期限が切れます。承認が降りた時点で残っているのは普通運賃だけ——この順序が、そのまま費用になっています。

前述のとおり、羽田〜福岡なら往復14,000円、総額の2割超です。

これはプロセス管理の設定では解決しません。 通知を増やしても、リマインダーを設定しても、承認者が見るまでの時間は短縮されますが、承認が降りてから人が予約するという順序は変わりません。承認遅延の原因と対策で通知・代理承認による短縮を扱いましたが、短縮には下限があります。

つまり、出張申請をkintoneで仕組み化しても、費用の2割を決めている部分は手つかずで残ります。 電子化で削減できるのは工数であって、運賃ではありません。ここを期待値として最初に持っておくと、導入後に「思ったより安くならない」とならずに済みます。

よくある質問（FAQ）

サンプルアプリはそのまま使えますか？

出発点としては使えます。ただし日当の計算ルールと、申請額と実額のずれの扱いは自社で決める必要があります。 サンプルはフォームの構造を示すもので、規程は入っていません。この2つを決めずに配布すると、運用開始後に必ず質問が集中します。

アプリはいくつに分けるべきですか？

月の出張件数が20件未満なら1アプリ、20〜200件なら2アプリが目安です。総務が手配を代行しているなら、件数が少なくても手配アプリを分ける価値があります。 承認済みで手配待ちのレコードが見えるかどうかが分かれ目です。

事後申請は許すべきですか？

許したうえで件数を数えてください。 禁止すると、急な出張が申請されないまま実行され、記録が残りません。事後フラグを立てて月次で件数を見て、増えているなら承認速度が問題です。

交通費の明細は何行くらい持たせるべきですか？

テーブル（サブテーブル）で可変にします。固定の行数を決め打ちすると、必ず足りない出張が出ます。1レコードあたり20行を超えるようなら、交通費を別アプリに切り出すことを検討してください。

海外出張も同じアプリで扱えますか？

フォームは共通化できますが、承認ルートは分けてください。 渡航先の安全情報確認、海外旅行保険の加入、為替レートの適用日など、国内にない項目が入ります。為替は申請時レートか精算時レートかを規程で決めておく必要があります。

経費精算システムを別に入れている場合はどうしますか？

出張申請（事前）をkintone、精算を経費精算システムに置く構成は成立します。ただし申請と精算の紐付けが人の手作業になる点に注意してください。承認した出張と、精算された金額が対応しているかを誰も突合していない、という状態になりがちです。この論点はkintoneの経費精算は承認後が詰まるで扱っています。

1Approvalでの実現方法

1Approvalは、いま作ったkintoneのプロセス管理の上で、承認が降りた時点で手配まで完了させる仕組みです。本記事で整理した設計論点のうち、いくつかが不要になります。

• 「手配待ち」の工程が消える — 承認がそのまま手配の実行になるため、3アプリ構成にする理由が無くなる
• 申請額と実額のずれが小さくなる — 承認から予約までの時間が無くなるため、事前購入運賃の期限切れが起きない。あらかじめ許容範囲を設定しておけば、差し戻しなしで進められる
• 立替と法人決済の混在が解消する — 費用は法人一括請求にまとまるため、支払手段を明細ごとに管理する必要がなくなる
• 精算アプリの入力が要らない — 手配データがそのまま費用データになるため、実額の転記が発生しない

承認ルートの設計はそのまま使えます。 プロセス管理を作り直す必要はなく、ステータス変更をトリガーにできます。

つまり、本記事の設計のうち「承認をどう回すか」は引き続き必要で、「承認のあとをどう回すか」が不要になる、という関係です。

なお同じ業務をMicrosoft 365で組む場合は、プラットフォームの制約が異なるため構成も変わります。Microsoft 365の出張申請｜2フロー構成で整理しています。

まとめ

kintoneで出張申請を作るとき、最初に決めるのはアプリをいくつに分けるかです。件数が月20件未満なら1アプリ、20〜200件なら2アプリ、手配を代行するなら手配アプリを分けます。

そして出張申請に固有の設計は4つ。申請額と実額のずれの許容範囲、日当の計算ルール、定期区間の控除、立替と法人決済の混在です。このうち最初の2つは、規程側の曖昧さを潰さないと数式に落とせません。

最後に期待値の話です。電子化で減るのは工数であって、運賃ではありません。 承認リードタイムが事前購入運賃の期限を超えるという構造は、プロセス管理の設定では変わりません。ここを変えたいなら、承認と手配の順序そのものを見直す論点になります。

主な参照先

• 出張申請｜すぐに使えるサンプルアプリ（kintone）
• 旅費精算申請｜すぐに使えるサンプルアプリ（kintone）
• 交通費申請｜すぐに使えるサンプルアプリ（kintone）
• K-Apps 旅費交通費精算 with 乗換案内Biz｜プラグイン・連携サービス
• kintoneで旅費精算申請を効率化｜Toyokumo kintone Blog
• kintoneで経費精算業務をシステム化する方法｜テクバン

※サンプルアプリの構成・連携サービスの仕様は2026年9月時点で確認した公開情報です。最新の情報は各公式サイトでご確認ください。