Odooの承認ワークフロー(Approvals)|「誰で止まっているか」が見える仕組みと設計

「あの申請、承認もらえましたか」

社内でこの確認に使っている時間は、意外と長いものです。備品の購入、出張の申請、契約書の押印依頼、社外への持ち出し許可。どれも小さな判断ですが、止まると仕事が進みません。

原因をたどると、たいてい同じところに行き着きます。承認する人が、申請が来ていることを知らなかったのです。チャットは流れ、メールは埋もれ、口頭の話は忘れられる。誰も悪くないのに、止まっています。

Odoo(オドゥー:オープンソース由来の統合業務アプリ群)の承認アプリは、申請を1つの一覧に集める仕組みです。承認者は自分の未処理を1か所で見られ、申請者は自分の申請がどこで止まっているかを自分で確かめられます。

経費・発注・休暇の承認は、もともと各アプリに組み込まれています。承認アプリの出番は、どのアプリにも属さない申請です(各アプリに組み込まれた承認との違い)。

承認アプリで申請を集めると、たとえば次のことが変わります。

  • 承認者ごとの未処理と、誰の手元で止まっているかが分かる
  • 申請者が自分で状態を見られ、催促の連絡が要らなくなる
  • いつ誰が承認したかが残り、後からたどれる
  • 承認の種類ごとに、承認する人と必要な人数を決められる

ただし、部門と役職で経路が細かく変わる稟議を守るなら、専用のワークフローサービスのほうが合います(設定より先に確かめること)。

では、何を承認の対象にすればよいのか。設計は、何を承認しないかを決めるところから始まります。答えは何を承認しないかに、良い点と注意点はメリットとデメリットにあります。

このアプリはEnterprise版限定です
Odooの承認アプリは、有償のEnterprise版が対象と案内されています。無料のCommunity版では利用できません。この記事はEnterprise版を前提に書いています。

目次

社内の承認が止まる原因は、たいてい「見えなさ」

依頼の経路がばらばらな状態と、1つの一覧に集まった状態を比べたのが、次の図です。

承認依頼がばらばらな状態と、一覧に集まった状態 チャット・メール・口頭・紙の回覧に依頼が分かれていると、承認者は依頼に気づかず、申請者は状態を確認できず、催促の連絡が業務時間を食い、記録も残らない。承認待ちの一覧に集まると、承認者ごとの未処理と止まっている場所が分かり、申請者が自分で状態を見られ、催促が要らなくなり、いつ誰が承認したかが残る。 承認依頼の集まり方 依頼の経路がばらばら チャットで依頼 メールで依頼 口頭で依頼 紙を回覧 承認者は依頼に気づかない 申請者は状態を確認できない 催促の連絡が業務時間を食う 記録も残らない 1つの一覧に集まる 承認待ちの一覧 備品購入 2件/出張 1件 持ち出し許可 3件 承認者ごとに未処理が分かる 誰の手元で止まっているか分かる 申請者が自分で状態を見られる 催促の連絡が要らなくなる いつ誰が承認したかが残る
承認依頼がばらばらな状態と、一覧に集まった状態

一覧に集めると、変わることは2つです。

  1. 承認者が、自分の未処理を1か所で見られる
  2. 申請者が、自分で状態を確認できる

効果が大きいのは2つ目です。「あの申請どうなりましたか」という確認が、そもそも要らなくなります。

記録が残る

もう1つ、副次的ですが大きな効果があります。いつ、誰が承認したかが残ることです。

紙とチャットの運用では、後から「これは誰が決めたのか」をたどれません。監査や社内の振り返りで困るのは、この部分です。

Odooの承認ワークフロー(Approvals)でできること

Odooの承認アプリは、おおむね次のような構成です(2026年8月時点の一般的な構成)。

「ワークフロー」とは、申請が承認を経て確定するまでの決まった流れのことです。回覧板の順番をシステムの上に置いたもの、と考えてください。

承認の種類を定義する

  • 「備品購入」「出張申請」「契約書の確認」のように、承認の種類(承認タイプ)を作る
  • 種類ごとに、承認する人を設定する
  • 種類ごとに、何人の承認が必要かを決める
  • 申請時に入力してもらう項目や、添付を求めるかも決められる

申請と承認

誰が何をするか
申請者種類を選んで申請を作成し、提出する
システム承認者の一覧に、未処理として表示する
承認者承認、または却下する
申請者自分の申請の状態を確認する

設定できる項目の細かな名称や範囲は、バージョンによって変わります。検討するときは、対象バージョンの公式資料で確認してください。

Odooの承認アプリのメリットとデメリット

機能と、後の章の設計・使い分けから、良い点と注意点をまとめると次のとおりです。使える版は、機能ごとに添えています。

メリット

  • 申請が1つの一覧に集まる:承認者は、自分の未処理を1か所で見られる。誰の手元で止まっているかも分かる
  • 申請者が自分で状態を確かめられる:「あの申請どうなりましたか」という確認が、そもそも要らなくなる
  • いつ誰が承認したかが残る:監査や社内の振り返りで、後から「誰が決めたか」をたどれる
  • 承認の種類ごとに決められる:承認する人、必要な人数、申請時の入力項目や添付の要否を、種類ごとに設定できる
  • 承認が業務の記録とつながる:購買・経費・休暇の承認は各アプリに組み込まれ、承認された発注はそのまま発注書になる。各アプリの承認は、Community版でも使える範囲がある

デメリット・注意点

  • 承認アプリはEnterprise版限定:Community版では利用できないと案内されている
  • 承認を増やしすぎると逆効果:承認者が中身を見なくなり、「通す作業」になる。形だけの承認は統制を弱める
  • 例外の手続きを決めないと形だけになる:承認者の不在・緊急時・本人の申請の扱いを決めていないと、現場が独自に回避する
  • 日本の稟議に合わせた作り込みは専用サービスが得意:部門と役職で経路が変わる設計や、Excel帳票のフォーム化は、専用のワークフローサービスのほうが深い

両方を並べると、次の図のとおりです。

Odooの承認アプリのメリットとデメリット 良い点は、申請が1つの一覧に集まる、申請者が自分で状態を確かめられる、いつ誰が承認したかが残る、承認の種類ごとに承認者と人数を決められる、各アプリの承認は業務の記録とつながること。注意点は、承認アプリはEnterprise版限定、承認を増やしすぎると通す作業になる、例外の手続きを決めないと形だけになる、日本の稟議に合わせた作り込みは専用サービスが得意なこと。 Odooの承認アプリのメリットとデメリット 良い点 申請が1つの一覧に集まる 承認者は未処理を1か所で見られる 申請者が自分で状態を見られる 催促の確認が要らなくなる いつ誰が承認したかが残る 監査や振り返りでたどれる 種類ごとに承認者と人数を決める 入力項目や添付の要否も 承認が業務の記録とつながる 承認された発注はそのまま発注書に 注意点 承認アプリはEnterprise版限定 各アプリ内の承認はC版にも範囲あり 増やしすぎると通す作業になる 承認者が中身を見なくなる 例外の手続きが要る 不在・緊急・本人申請を先に決める 細かな稟議経路は専用サービス 部門と役職で変わる経路・Excel帳票 C版=Community版(無料)/E版=Enterprise版(有償)
Odooの承認アプリのメリットとデメリット

注意点への備え方は、何を承認しないかと例外の手続きにまとめました。

承認フローの設計は「何を承認しないか」から始める

承認の仕組みを入れると、あれもこれも承認の対象にしたくなります。その結果が、業務の渋滞です。

承認の重さは、3段階に分けて考えます。

承認の重さを、3段階に分ける 1段目は承認しないで事後の記録だけ残す範囲で、日常の消耗品や少額の交通費など。この範囲を決めることが設計の出発点。2段目は上長1名がその場で判断する範囲で、部門の予算内で完結する支出や通常の出張。大半の申請はここに入るのが健全。3段目は複数名で別の視点を必ず通す範囲で、高額の支出・契約・社外への情報提供など、後戻りが難しい判断に限る。 承認の重さを、3段階に分ける ① 承認しない 事後の記録だけ残す 例:日常の消耗品、少額の交通費 止める価値より、待たせる損失が大きい この範囲を決めることが設計の出発点 ② 上長1名 その場で判断できる 例:部門の予算内で完結する支出、通常の出張 現場に近い人が判断したほうが速い 大半の申請はここに入るのが健全 ③ 複数名 別の視点を必ず通す 例:高額の支出、契約、社外への情報提供 後戻りが難しい判断に限定する 増やしすぎると、通す作業になる
承認の重さを、3段階に分ける(ベンチャーネットの整理)

日常の消耗品や少額の交通費は、承認せずに事後の記録だけを残します。部門の予算内で完結する支出や通常の出張は、上長1名がその場で判断します。複数名の承認は、高額の支出や契約、社外への情報提供のように、後戻りが難しい判断に限ります。

判断の基準

承認を置くかどうかは、次の1点で判断してください。

「その申請を止めて防げる損失が、待たせて生じる損失より大きいか」。

少額の消耗品を上長2名の承認にすると、防げる損失より、待つ時間の損失のほうが大きくなります。

会議で使える点検リスト:この申請を承認に残すか

今の申請書を1枚ずつ当てはめてください。□が1つも付かない種類は、承認から外す候補です。

  • □ 実行したあとで取り消すのが難しい(契約、社外への持ち出しなど)
  • □ 一人で決めると見落としやすい論点がある
  • □ 後から「誰が決めたか」をたどる必要がある(監査・取引先への説明など)
  • □ この1年で、実際に却下や差し戻しが起きている
  • □ 承認を置く理由を、1行で申請者に説明できる

承認を増やしすぎると起きること

  • 承認者が中身を見なくなり、「通す作業」になる
  • 申請者が、承認の要らないやり方を探し始める
  • 「承認したのに問題が起きた」ときの責任があいまいになる

3つ目が深刻です。形だけの承認は、統制を強めるどころか弱めます。

承認の例外の手続きを、必ずセットで決める

承認の設計でいちばん忘れられるのが、例外の手続きです。

必ず起きること

  • 承認者が休んでいる(出張、休暇、病気)
  • 急いでいる(当日中に決めないと機会を逃す)
  • 承認者本人が申請者になる

この3つは、必ず起きる場面です。決めていないと、現場が独自に回避します。

「部長が不在なので、とりあえず進めておきました」が当たり前になると、仕組みそのものが形だけになります。

決めておくこと

場面決めること
承認者の不在代理の承認者を誰にするか。事前に設定するのか、その都度か
緊急時先に実行して事後承認とする範囲。その場合の記録の残し方
承認者が申請者上位の承認者に回すのか、別部門の同格者に回すのか

例外の手続きは、抜け道とは別物です。決めておけば、記録に残る形の例外になります。決めていなければ、記録に残らない例外が生まれます。

承認は「監視」ではありません

承認の仕組みを入れると、細かく管理するためだと受け取られることがあります。そうなると、現場の抵抗が生まれます。

目的の説明を、先にしてください

承認の目的は、次のどちらかであるべきです。

  • 判断の品質を上げる(一人で決めると見落とす点を、別の目で確認する)
  • 記録を残す(後から「誰が決めたか」をたどれるようにする)

「信用していないから確認する」のではありません。ここを説明せずに導入すると、申請する側は「疑われている」と感じます。

実務上の勧め

  • 承認を置く理由を、種類ごとに1行で説明できるようにする
  • 説明できない承認は、置かない
  • 導入後、却下がほとんど出ていない種類は見直す

3つ目は、有効な点検方法です。1年間ほぼ全件が承認されている種類は、承認である必要がないかもしれません。事後の記録だけで足りる可能性があります。

社内への説明と定着の進め方は Odooを社内に定着させる方法 にまとめています。

各アプリに組み込まれた承認との違い

この違いを押さえておかないと、設計が重複しがちです。

Odooでは、いくつかのアプリに承認の仕組みがもともと組み込まれています。

対象どこで承認するか
立替経費の精算経費精算アプリの中
発注(購買)購買アプリの中
休暇の申請休暇管理アプリの中
工数の確定工数管理アプリの中

これらは、それぞれのアプリで完結させてください。承認アプリで作り直す必要はありません。

では、承認アプリは何に使うのか

承認アプリの出番は、どのアプリにも属さない申請です。

  • 備品の購入依頼(発注の前段階の相談)
  • 出張や外出の届け出
  • 社外への持ち出し許可
  • 各種の社内手続き

紙の稟議書や申請書で回していたものが、ここに入ります。

経費と発注の詳細は、それぞれの記事にまとめています。

承認アプリのCommunity版とEnterprise版の違い

Odooには、無料のCommunity版と有償のEnterprise版があります。

Community版は、オープンソースとして無料で使える版です。ただし、サーバーの用意・アップデート・障害対応は自社の責任です。公式サポートの対象外でもあります。

承認アプリは、Enterprise版が対象です。Community版では利用できないと案内されています。

一方で、各アプリに組み込まれた承認との違いのとおり、購買や休暇の承認は各アプリの中に組み込み済みです。そちらはCommunity版でも利用できる範囲があります。

承認アプリがなければ承認ができない、というわけではありません。汎用の申請フォームが要るかどうかで、判断が分かれます。

どの機能がどちらの版で使えるかは、バージョンによって変わります。検討するときは、必ず対象バージョンで確認してください。

詳しくは Odoo Community版とEnterprise版の違い をご覧ください。

ベンチャーネットが承認アプリの設定より先に確かめること

ERP導入支援を手がけるベンチャーネットは、NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。承認の相談でも、最初に触るのはシステムではなく、今の申請書の束です。

今の申請書・稟議書を、全部並べる

紙、Excel、チャットの定型文まで含めて、申請の種類を一覧にします。種類ごとに、おおよその件数と、却下や差し戻しの有無を聞きます。ここで浮かび上がるのが、「誰も却下したことがない種類」です。

各アプリの承認に移るものを、先に振り分ける

経費・発注・休暇・工数の申請は、それぞれのアプリの承認に任せます。承認アプリに残るのは、どのアプリにも属さない申請だけです。

残った申請を、点検リストで絞る

承認に残すかの点検リストで、□が1つも付かない種類は、承認をやめて記録だけ残す案を出します。紙の様式は再現せず、標準の形に合わせます(Fit to Standard:標準機能に業務を合わせる考え方)。

例外3場面の決まりを、種類ごとに決める

不在・緊急・本人申請の扱いを決めてから、承認者を設定します。順番を逆にすると、稼働後に「進めておきました」が始まるためです。

承認アプリが本当に要るかを、正直に判断する

絞った結果、汎用の申請がほとんど残らない会社もあります。その場合は、Enterprise版の承認アプリを前提にしない構成も選択肢に入れます。

逆に、部門と役職で経路が細かく変わる稟議を守る必要がある会社もあります。その場合は、専用のワークフローサービスのほうが合うとお伝えします。上場準備などで内部統制まで含めて承認を組む規模なら、NetSuiteの承認ワークフロー実装ガイドも参考になるはずです。

判断の軸は、3〜5年後の組織の姿です。拠点や部門が増える見込みなら、承認後の処理までつながるOdooの利点が生きてきます。

他のアプリとのつながり

アプリつながり方
経費精算精算の承認は経費側で完結する。役割を分ける
購買管理発注の承認は購買側で完結する。備品の購入相談は承認アプリ側
人事管理申請者・承認者の所属と上長関係の元データ
社内チャット申請ごとのやり取りが、その記録に残る
文書管理申請の根拠となる書類の最新版を、探さずに済む状態にする

アプリごとの詳細は、それぞれの記事にあります。

承認アプリに対応する有名SaaS(ジョブカン・コラボフロー)

ワークフローシステムをすでに使っているなら、Odooの承認アプリはその置き換え候補です。主なサービスとの対応は次のとおりです。

Odooの承認アプリは、Enterprise版限定です。Community版では利用できません。

使っているSaaSOdooでの対応一言で言うと
ジョブカンワークフロー承認ワークフロー(Approvals・Enterprise版)一部重なる。申請と多段階の承認は重なるが、申請書テンプレートの数と条件分岐の細かさはジョブカンが厚い
コラボフロー承認ワークフロー(Approvals・Enterprise版)一部重なる。承認経路の設計は重なるが、Excelの帳票をそのままWebフォーム化する機能はコラボフローにしかない

機能の違い

  • OdooにあってワークフローSaaSにないもの:承認した内容が、そのまま業務の記録として動くこと。購買・経費・休暇の承認は各アプリに組み込まれており、承認された発注はそのまま発注書になる
  • ワークフローSaaSにあってOdooにないもの:既存のExcel帳票をそのままフォーム化する機能、申請書テンプレートの豊富さ。複雑な条件分岐や代理承認の作り込み、日本の稟議の慣習に沿った経路設計も含む

日本の稟議に合わせた作り込みには、大きな差があります。部門と役職の組み合わせで経路が変わる、といった設計は専用サービスのほうが得意です。

課金構造の違い

2社とも、ユーザー単位の課金です。

ジョブカンワークフローは、ユーザー単価×登録ユーザー数で月額が決まり、最低利用料金が設定されています(停止済みのユーザーは請求対象外)。

コラボフローのクラウド版は、最低ユーザー数が決まっていて、超えると1ユーザー単位で追加する形です。最低利用期間があり、利用料にはサポートサービスの利用料が含まれます。

(※出典:各社公式サイト、2026年9月確認。課金の型のみ。金額や条件は改定されることがあるため、検討時に各社の公式ページでご確認ください)

Odoo Enterprise版は、全アプリ一律のユーザー課金です。承認アプリだけ使っても、他のアプリまで使っても、1ユーザーの単価は変わりません。金額の詳細は Odooの料金体系を解説 を参照してください。

比べるときは、申請する人の数を数えてください。承認するのは一部でも、申請するのは全社員になりやすい領域です。どちらの体系でも、この人数が費用を決めます。

置き換えのメリット

  • 承認した内容が業務の記録として動く(承認された発注がそのまま発注書になる)
  • 申請の根拠になる見積や在庫の情報を、同じ画面で見ながら承認できる

置き換えのデメリット・向かないケース

  • 既存のExcel申請書をそのまま使いたいなら、専用サービスのほうが向いている
  • 部門と役職で経路が細かく変わる稟議を運用しているなら、専用サービスの経路設計のほうが深い
  • 購買・経費・休暇の承認は、Odooでは各アプリに組み込まれている(各アプリに組み込まれた承認との違い)。承認アプリで作り直さないこと

分かれ目は、承認した後の処理まで同じ場所でつなげたいかどうかです。

他のアプリの対応表は Odooで置き換えられるSaaS対応表 にまとめています。

バージョンと機能の更新について

Odoo 19.0は2025年9月にリリースされました。標準サポートの終了は2028年9月(予定)と、公式に記載があります。

その後、19.1(2026年1月)・19.2(2026年3月)・19.3(2026年5月)・19.4(2026年7月)が順に提供されています。

19.1〜19.4は、Odooオンラインで先に提供されました。Odoo.shとオンプレミスは対象外でした(公式のサポート表にN/Aと明記)。

2026年9月には、次のメジャー版のOdoo 20が公開されました。Odoo.shやオンプレミスの会社も、Odoo 20に上げれば、19.1〜19.4の新機能をまとめて受け取れます。

違うのは、新機能を受け取る時期です。早く使いたいならOdooオンライン。自社で管理したいなら、Odoo.shかオンプレミスで年1回のメジャー版に合わせます。Odoo 20の変更点はOdoo 20の新機能まとめで整理しています。

承認アプリに直接かかわる変更は、19.1〜19.4の公式リリースノートに記載が見つかりませんでした。記載が見つからなかったというだけで、変更がなかったとは言い切れません。検討するときは、対象バージョンの公式ドキュメントで最新の状況を確認してください。

この更新の流れは、Enterprise版の話です。Community版は、この流れの対象ではありません。承認アプリ自体がEnterprise版を対象としている点は、この記事全体の前提です。

※出典:Odoo公式のリリースノートおよびドキュメント(2026年9月確認)

よくある質問

Q1. 承認の段階は、いくつまで作れますか?

種類ごとに、承認者と必要な人数を設定できます。ただし、段階を増やすほど申請は滞ります。

大半の申請は、上長1名で足りるはずです。複数名の承認は、後戻りが難しい判断に限ってください。

Q2. 承認者が不在のときはどうなりますか?

決めていなければ、現場が独自に回避します。代理の運用は、先に決めておいてください。

「不在なので進めておきました」が当たり前になると、仕組みそのものが意味を失います。

Q3. スマートフォンから承認できますか?

Odooは、ブラウザで使うPWA(アプリのように使えるWebアプリ)とストアアプリで、スマートフォンから使えます。公式ドキュメントに版の限定の記載はありません(出典:Odoo公式ドキュメント「Odoo mobile apps」、2026年10月確認)。承認アプリ自体は、Enterprise版が対象です。

ただし、操作性は実機で確認してください。承認は移動中に行われることが多く、ここが使いにくいと滞留の原因になります。

Q4. 紙の稟議書と同じ様式にできますか?

同じ様式を再現しようとしないでください。紙の様式には、紙だから必要だった項目が含まれています。

回覧の順序を記す欄や、押印欄はその代表です。再現すると、非効率まで引き継ぎます。

考え方は OdooとFit to Standard|標準機能に業務を合わせる考え方 を参照してください。

Q5. 承認の履歴は、どのくらい残りますか?

申請ごとに、承認の記録が残ります。保存期間の方針は、自社で決める必要があります。

監査で参照する可能性がある種類は、あらかじめ保存の考え方を決めておいてください。

Q6. Odooの承認アプリのメリットとデメリットは何ですか?

止まっている場所が見える一方でEnterprise版限定です。

申請が1つの一覧に集まり、申請者も承認者も状態を確かめられます。いつ誰が承認したかも残ります。
一方、承認アプリはCommunity版では利用できません。日本の稟議に合わせた細かな経路設計は、専用サービスのほうが得意です(メリットとデメリット)。

まとめ

Odooの承認ワークフローが変えるのは、申請の速さそのものではありません。今どこで止まっているかが、申請者にも承認者にも見えるようになることです。

設計は、何を承認するかではなく、何を承認しないかから始めてください。基準は、止めて防げる損失が、待たせる損失より大きいかどうかです。

例外の手続きも、必ずセットで決めます。承認者の不在、緊急時、承認者本人が申請者になる場合の3つです。

承認は監視ではありません。目的は、判断の品質を上げることと、記録を残すことです。この説明を先にしてから入れてください。

経費・発注・休暇は各アプリの承認に任せる。承認アプリに移すのは、紙の稟議だけです。入れたあとは、ほぼ全件が通る種類を減らす点検を運用に組み込みます。

1年後の月曜の朝、部長の未処理一覧には、判断が本当に要る申請だけが数件並んでいます。社内チャットから「あの申請どうなりましたか」の一言が消え、承認の種類は導入時より少なくなっているはずです。

もう少し詳しく知りたい方へ

ベンチャーネットは、ERP導入支援を手がける会社です。NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しているため、特定の製品に偏らない立場でご提案できます。

「今の稟議のうち、どれを承認から外すか」という整理からご相談を承っています。

関連記事

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

持田 卓臣(もちだ たくおみ)
株式会社ベンチャーネット 代表取締役

ヒューレット・パッカード社でITコンサルタントとして従事した後、2005年に株式会社ベンチャーネットを設立。
Oracle NetSuite Solution Provider Partner として、中堅・中小企業向けクラウドERP「NetSuite」の導入・運用支援を提供しています。
SEO・広告・SNS・ウェブ・MA・SFAと一気通貫で培ってきたデジタルマーケティング領域の業務知見を活かし、NetSuiteを軸とした経営DXを支援しています。
著書:『普通のサラリーマンでもすごいチームと始められる レバレッジ起業「バーチャル社員」があなたを救う』(KADOKAWA、2020年)

目次