電子カンバンの導入で最初に決めるべきことは、端末やクラウド製品ではありません。「何が起きたら、誰が、どこへ、何個を補充し、誰の確認でループを閉じるか」というプルのルールです。紙カードを画面へ置き換えるだけでは、紛失カードが未確認アラートに変わるだけで、欠品、過剰補充、在庫差異の原因は残ります。本稿では、タイ工場の生産・物流・IT責任者が、かんばん方式のシステム化をRFP、提案型90日PoC、FAT・SAT、段階展開まで具体化できるよう、責任境界と受入証跡を実務順に整理します。
先に結論｜電子カンバンは「プルの閉ループ」を設計してから電子化する
電子カンバンは、単なるデジタルカードではありません。少なくとも、発行契機、補充数量、供給元、供給先、受領確認、例外処理、監査証跡を一つの状態遷移として管理する仕組みです。導入判断では、次の三つを分けてください。
- 現物の真実：容器や部品が実際にどこにあり、使える状態か。
- 在庫の真実：ERPやWMSが保持する数量、ロット、引当、品質状態は何か。
- 信号の真実：補充要求が発行済み、確認済み、供給中、到着済み、取消、例外のどこにあるか。
電子カンバンサービスが在庫数量まで独自に持つと、ERPやWMSとの二重台帳になりやすくなります。一方、ERPだけで秒単位の現場信号を表そうとすると、作業者が必要な状態や通信断時の制御が不足する場合があります。どのシステムが何を正本として持つかを決め、重複・遅延・取消が起きても照合できる設計が出発点です。
紙かんばんが常に劣るわけでもありません。品種と容器数が少なく、供給ルートが固定され、信号件数が低く、目視で異常が分かり、遠隔監視や他システム連携に価値が少ない工程では、紙の単純さが強みになります。反対に、複数棟や外部サプライヤーをまたぐ、信号量が多い、リードタイム変動が大きい、カード紛失が起こる、遠隔監視や監査・照合が必要という工程では、電子化を検討する意味があります。
電子カンバンとは何か｜トヨタ生産方式のプルをイベントでつなぐ
トヨタ自動車はToyota Production Systemを「自働化」とJust-in-Timeの二本柱で説明し、Just-in-Timeを必要なものを必要な時に必要な量だけつくる考え方として示しています。また、後工程が前工程から必要なものを引き取り、前工程が引き取られた分を補充するプルの関係を説明しています。かんばんは、その必要数量とタイミングを調整するための手段です。
この原則を電子化するなら、画面にカード画像を表示することより、プルを発生させた事実と、その後の状態を正確につなぐことが重要です。最小の電子カンバンイベントには、次の要素が必要です。
| 要素 | 決める内容 | 受入で確認する証拠 |
|---|---|---|
| Trigger | 空容器、使用完了、最小量、計画変更など何を契機にするか | 発行元イベントと時刻 |
| Quantity | 固定容器量、実使用量、端数、上限をどう扱うか | 計算根拠と丸め履歴 |
| Source | 倉庫、スーパー、前工程、外部供給者のどこから出すか | 供給元決定ログ |
| Destination | ライン、設備、投入点、受入場所をどう特定するか | ロケーションIDと読取結果 |
| Acknowledgement | 誰が、どの時点で受領・着手・到着を確認するか | ユーザー、端末、時刻、状態 |
| Exception | 欠品、品質保留、代替、ルート変更、取消をどう扱うか | 理由、承認、復旧履歴 |
| Audit | 発行から完了までを一つのIDで追えるか | 相関IDとイベント列 |
「空箱をスキャンしたら補充指示を出す」だけでは足りません。同じ箱を二度読んだ場合、読み取り後に通信が切れた場合、供給元に在庫がない場合、代替部品が必要な場合、品質保留になった場合、予定より先に現物だけ届いた場合まで、閉ループとして定義します。
現状を一枚にする｜かんばん方式 システム化の前に観察する項目
RFPを書く前に、代表品目を一つ選び、現行の一周を歩いてください。会議室で標準手順だけを聞くのではなく、通常シフト、休憩交代、夜勤、月末、計画変更、欠品、品質保留を観察します。次の項目を一枚の現状表へ落とします。
- 部品番号、品名、版、代替関係、品質区分
- 容器ID、荷姿、標準入数、端数の扱い
- ライン側のスーパー、投入点、最大・最小容器数
- 供給元、供給ルート、ミルクラン、締め時刻
- 発行契機、発行者、スキャン場所、紙カードの移動
- 受領、ピッキング、出発、到着、投入の確認点
- ERP・WMS・MES・Excel・紙帳票へ入力する内容
- 欠品、誤品、破損、品質保留、戻り品、代替、緊急便
- 通信、端末、プリンタ、ラベルが使えない時の手作業
- 日次照合の時刻、差異を直せる役割、承認者
見つけたいのは「標準通りの最短経路」ではなく、信号と現物が分岐する場所です。たとえば、作業者が容器を空にする前にカードを抜く、同じカードをまとめて運ぶ、倉庫が経験で先出しする、ライン停止を避けるため電話で緊急依頼する、といった行動には理由があります。安全在庫が不足しているのか、巡回周期が合わないのか、品質保留が見えないのか、計画変更が遅いのかを分けます。例外を画面に移すだけでは改善になりません。
現状のライン供給や構内物流から整理したい場合は、タイ工場の構内物流改善事例も参照してください。生産計画の変動が補充へ与える影響を検討する場合は、タイ工場の生産計画シミュレーションと合わせると、計画系と実行系の境界を整理しやすくなります。
「信号の正本」と「在庫の正本」を分けるシステム境界
ISA-95は、企業システムと製造制御を統合するための技術中立なモデルを定めています。Level 3は製造オペレーション管理、Level 4は事業計画・物流を扱います。特定の電子カンバン製品を規定するものではありませんが、ERP、MES、現場制御の責任を話し合う共通言語として使えます。
代表的な責任分担は次のように整理できます。ただし、これは製品に依存しない出発点であり、自社の既存構成に合わせて決めます。
| 層・システム | 持たせやすい責任 | 持たせる際の注意 |
|---|---|---|
| ERP | 購買、製造指図、品目・取引先、会計影響、拠点在庫の企業正本 | 現場の秒単位状態やオフライン端末制御を背負わせすぎない |
| WMS | 倉庫ロケーション、ピッキング、補充、ロット・物流単位、庫内在庫 | ライン投入後の消費事実をどこで確定するか決める |
| MES | 生産実績、工程投入・完了、設備・作業イベント、仕掛状態 | 購買や企業在庫の正本を重複させない |
| PLC・Edge | センサー、ボタン、設備信号、短周期収集、一時バッファ | 業務判断や長期証跡を制御機器だけに閉じ込めない |
| 電子カンバン | 発行、確認、割当、搬送中、到着、取消、例外という信号状態 | 独自在庫台帳や独自品目マスタを増やさない |
境界を決めるには、画面単位ではなくイベント単位の契約表を作ります。たとえば「容器消費」というイベントなら、発生元、必須項目、相関ID、送信時刻、受信確認、重複判定、取消、再送、保持期間、責任者を記載します。ERPへの連携が遅れても電子カンバン信号を継続してよいのか、WMSの在庫が品質保留なら補充を止めるのか、MESの計画変更で未着手信号を再計算するのかを明示します。
ここで重要なのが冪等性です。同じイベントが二度届いても二重補充を起こさず、逆順で届いても状態を壊さず、取消と再発行を追跡できる必要があります。「リアルタイム連携」という言葉だけでは、遅延・重複・欠落時の動作が分かりません。RFPでは正常時の速度だけでなく、失敗時の整合性を回答させます。
識別と読取｜バーコード・QR・RFIDは運用から選ぶ
GS1は標準の働きをidentify、capture、shareに分けて説明し、バーコードやRFIDをデータキャリアとして位置付けています。また、GTINは商品・サービス、GLNは組織・場所、SSCCは物流単位、GRAIやGIAIは資産の識別に使えると説明しています。これらは、企業間や拠点間で一意性が必要な場合の有力な選択肢ですが、工場内の電子カンバンが必ずGS1識別子を使わなければならないという意味ではありません。
識別方式は「新しい技術」から選ばず、対象、距離、汚れ、遮蔽、誤読リスク、再発行、単価、保守、取引先との共有を基準に選びます。
| 方式 | 適する場面 | 主な確認事項 |
|---|---|---|
| 1Dバーコード | 既存ラベル資産があり、目視で一件ずつ読む | 印字品質、桁数、チェック、汚れ、再発行 |
| QR・2Dコード | 小面積にIDと属性を持たせ、スマート端末も使う | 情報量を増やしすぎない、版、誤った写真読取 |
| RFID | 見通し外・一括読取や通過検知に価値がある | 読取範囲、金属・液体、重複、未読、タグ耐久 |
| PLC・センサー信号 | 設備の排出・消費と直接つなぐ | 誤検知、保守運転、手投入、設備時刻、再送 |
| 手動ボタン | 手袋作業で単純な発行だけが必要 | 誤押下、二重押下、対象容器の特定、取消 |
バーコードには識別子に加え、シリアル、バッチ・ロット、日付などの属性をエンコードできる場合があります。ただし、ラベルに多くの変動情報を固定すると、マスタ変更や容器転用で不整合が生じます。原則は、永続的な識別子を読み、最新の属性を正本システムから参照する設計です。オフライン継続に必要な最小属性だけを端末へ安全にキャッシュする構成も検討します。
OPC UAは、センサーや制御システムからMES、ERPまでを対象とし、情報、メッセージ、通信、適合性のモデルを定義しています。Client/ServerとPubSubをサポートするため、設備イベントやEdge連携の候補になり得ます。ただし電子カンバンの必須プロトコルではありません。既存設備、遅延要件、セキュリティ、保守能力に合う場合だけ採用し、業務イベントの意味は別途定義します。
作業指示 システムとして必要な状態遷移
電子カンバンを作業指示システムとして使うなら、単なる「未完了／完了」では現場を制御できません。次は提案例であり、実際の状態名と遷移は自社業務に合わせて設定します。
| 状態 | 意味 | 許可する主操作 | 禁止・統制 |
|---|---|---|---|
| Issued | 消費等により補充要求が発生 | 確認、取消申請 | 二重発行を相関IDで拒否 |
| Acknowledged | 供給側が要求を認識 | 割当、保留 | 無権限者の数量変更を禁止 |
| Assigned | 供給元・担当・ルートが決定 | ピッキング開始 | 品質保留在庫の割当を拒否 |
| In Transit | 現物が供給元を出発 | 到着、例外登録 | 供給元への巻戻しは承認制 |
| Arrived | 指定場所で受領確認 | 投入、差異申告 | 誤ロケーションを警告または停止 |
| Closed | ループ完了 | 参照、監査 | 通常ユーザーによる編集を禁止 |
| Exception | 欠品、破損、代替、通信等 | 暫定処置、承認、再開 | 理由なし解除を禁止 |
| Cancelled | 有効な取消が完了 | 再発行 | 元信号との関連を保持 |
状態遷移ごとに、「誰が」「何を読んで」「どの条件なら」「どの次状態へ進めるか」を決めます。数量を手修正できる場合は、変更前後、理由、承認者を残します。緊急補充は通常ループから外して隠すのではなく、緊急理由、発行権限、後追い照合を持つ例外ルートとして設計します。
表示も役割別に変えます。ライン作業者には次の一手と異常だけ、物流担当には優先順位とルート、班長には滞留とエスカレーション、管理者にはマスタ・連携・監査を見せます。全員へ同じダッシュボードを見せると、情報量が増えるだけで判断が遅くなります。
通信断と例外｜止めないために「続けない処理」も決める
タイ工場では、無線の死角、端末故障、クラウド接続断、ERP停止、プリンタ停止を想定します。重要なのは「オフライン対応あり」という機能名ではなく、通信断中に何を継続し、何を止めるかです。在庫を変える高リスク処理を全てオフラインで許すと、同じ容器を複数端末が扱い、復旧時の競合が増えます。
処理を次の三段階に分ける方法があります。これは提案分類です。
- 継続可能：ローカルに有効なマスタと未使用IDがあり、競合が限定される読取・確認。
- 条件付き継続：班長承認、数量上限、対象ゾーン限定で手作業票へ退避できる処理。
- 停止：品質解除、代替確定、同じ在庫を競合更新する操作、権限照会が不可欠な操作。
手作業フォールバックには、発行時刻、容器、品目、数量、供給元・先、理由、記録者、承認者、一意な仮IDを残します。復旧後は単にまとめて入力せず、既存信号との重複、時系列、現物、在庫、品質状態を照合してから取り込みます。紙の退避票を廃止することではなく、非常時に管理可能な形で使い、確実に電子記録へ戻すことが目的です。
例外シナリオは少なくとも次を試します。
- 同一コードを同じ端末、別端末から連続読取する
- 発行直前、発行直後、確認直前、到着直前に通信を切る
- 供給元在庫なし、品質保留、代替品、端数容器を発生させる
- ルート変更、優先順位変更、取消と再発行を逆順で受信する
- 端末紛失、バッテリー切れ、アプリ強制終了、時刻ずれを起こす
- プリンタ停止とラベル再発行で旧ラベルが残る状態をつくる
- ERPまたはWMSから遅延・重複・不正形式のメッセージを送る
- 復旧後に現物、信号、在庫、インターフェースキューを照合する
復旧完了は「画面が戻った」ではありません。未送信イベントがなく、重複が排除され、例外が担当者に割り当てられ、ERP・WMS・MESの必要な後続処理が完了し、現物との日次照合が説明可能になった時点です。
在庫管理 見える化は色付きダッシュボードより定義が先
在庫管理の見える化では、赤・黄・緑の画面を作る前に、分母と時刻を定義します。「遅延」なら、発行から確認、確認から出発、出発から到着のどこを測るのか。「不足」なら、現物不足、引当可能不足、品質利用可能不足、信号数に対する容器不足のどれかを分けます。
提案する運用ビューは次の通りです。しきい値はすべて自社基準線から決める提案値であり、外部ベンチマークではありません。
| ビュー | 指標の例 | 判断につなげる問い |
|---|---|---|
| ライン | 未到着信号、到着予測、緊急補充 | 次に止まる恐れがある投入点はどこか |
| 物流 | 未確認、供給中、ルート別滞留 | 誰へ割り当て、どの便を変更するか |
| 倉庫 | 欠品、品質保留、代替候補 | 信号を処理できない根本理由は何か |
| 生産管理 | 計画変更後の残存信号、消費変動 | 計画とプルの矛盾をどこで解くか |
| IT | 連携失敗、端末オフライン、重複排除 | 業務影響のある障害をどう優先するか |
| 経営 | 欠品停止、緊急便、差異、改善推移 | 投資後にループの安定性が上がったか |
個人の処理件数だけを強く評価すると、先行確認、理由コードの省略、例外の隠蔽を招くおそれがあります。目的は作業者の監視ではなく、信号設計、ルート、容器数、マスタ、計画、設備、供給能力を改善することです。個人と結び付くログを扱う場合は、目的、閲覧権限、保持、利用範囲を社内の責任者と確認します。
RFP要件｜回答可能・採点可能・受入可能にする
電子カンバンのRFPは機能一覧ではなく、受入試験の原型にします。各要件へIDを付け、必須・推奨、回答方式、前提、制限、証拠、PoC対象、契約への反映先を持たせます。「対応可能」という回答ではなく、標準、設定、個別開発、外部製品、対象外、将来計画を選ばせます。
| RFP領域 | 回答を求める内容 | デモ・PoCで見る証拠 |
|---|---|---|
| プルルール | 発行、数量、上限、取消、再発行 | 指定シナリオの状態履歴 |
| 状態管理 | 状態、遷移、権限、SLA警告 | 役割別画面と監査ログ |
| 識別 | 容器・品目・場所・物流単位のID | 誤読、重複、再発行試験 |
| 連携 | ERP、WMS、MES、Edgeの契約 | 遅延・重複・逆順・再送履歴 |
| オフライン | 継続・停止・キュー・照合 | 通信断から復旧までの実機試験 |
| 例外 | 欠品、品質、代替、緊急、ルート | 理由・承認・復旧の証跡 |
| 多言語 | タイ語・英語・日本語のUIと教育 | タイ人作業者による完遂 |
| セキュリティ | 認証、権限、暗号、ログ、脆弱性 | 設定、拒否ログ、運用手順 |
| 運用 | 監視、バックアップ、変更、保守 | 障害訓練、復元、版管理 |
| 展開 | 移行、並行、戻し、拠点展開 | 切替リハーサルと判定資料 |
失格条件も先に定めます。たとえば、重複イベントで二重発行する、監査ログを管理者が痕跡なく削除できる、通信断後の照合方法がない、データを標準形式で取り出せない、保守終了条件が開示されない、といった条件です。これらは提案例であり、重大性は自社の品質・供給・情報セキュリティリスクに合わせて決めます。
価格はライセンスだけで比較しません。端末、スキャナー、タグ・ラベル、プリンタ、無線改善、Edge、接続開発、マスタ整備、データ移行、テスト、教育、現地支援、クラウド、監視、保守、変更、将来拠点までTCO表へ分けます。本稿では市場価格や削減率を提示しません。ベンダーには数量と単価、初期と継続、必須と選択、前提数量、為替・税、増加条件を分けて回答させます。
タイ投資委員会（BOI）のスマートかつ持続可能な産業への高度化施策に関する公式資料には、所定の条件の下で、自動化、デジタル技術、ソフトウェア・ITシステム、クラウドサービスに関係する対象が含まれます。ただし、電子カンバン導入が自動的に優遇対象になるわけではありません。対象活動、投資内容、申請時期、証拠、最新要件をBOIおよび専門家へ確認してから投資判断へ反映してください。
提案型90日PoC｜製品デモではなく展開判断の証拠を作る
以下の90日は提案する検証枠であり、外部標準や成功保証ではありません。繁閑、シフト、供給周期、連携数に応じて期間を調整します。重要なのは日数を消化することではなく、最も危険な仮説を本番相当条件で確かめることです。
提案Day 0–15｜基準線と対象ループを固定する
一つのライン、一つのスーパー、代表品目群、代表シフトへ絞ります。現行の信号件数、欠品、緊急補充、カード紛失、差異、巡回、処理時間を、定義付きで記録します。ここで得る値は外部ベンチマークではなく、自社の比較基準です。
プルルール、容器、供給元・先、状態、例外、手作業、システム境界、テストID、合否決定者を固定します。都合のよい品目だけでなく、端数、代替、品質保留、計画変更がある品目を含めます。
提案Day 16–30｜データ契約と最小構成をつなぐ
品目、容器、場所、ユーザー、ルートの正本を確定し、ERP・WMS・MESと電子カンバンのイベント契約を接続します。相関ID、重複判定、取消、再送、監視、保持を決めます。端末登録、権限、ラベル、タイ語表示、監査ログも構成管理へ入れます。
提案Day 31–60｜通常・ピーク・例外を現場で回す
タイ人作業者が実端末、実ラベル、実ルートで、発行から到着までを処理します。通常件数だけでなく、シフト開始、休憩後、計画変更、同時多発、欠品、誤品、代替、戻りを含めます。平均だけでなく、未確認の山、長時間滞留、再読取、監督者呼出しを記録します。
提案Day 61–75｜意図的に壊して復旧する
通信断、ERP停止、メッセージ遅延・重複・逆順、端末紛失、プリンタ停止、誤マスタ、権限外操作を注入します。止める処理が止まり、続ける処理が限定され、復旧時に二重補充を起こさず、手作業分を照合できることを確かめます。
提案Day 76–90｜証拠をそろえて展開を判定する
要件IDとテストIDを結び、入力、期待、実績、ログ、画面、現物確認、実行者、日時をそろえます。未解決課題には重大度、回避策、期限、責任者を付けます。判定は「展開」「条件付き展開」「再試験」「中止」の提案4区分とし、営業デモの印象ではなく受入委員会の証拠で決めます。
提案スコアカードとTCOワークシート
評価配点も外部基準ではなく提案例です。自社の供給停止、品質、監査、保守リスクに合わせて重みを変更してください。重大失格条件は、加点で相殺させません。
| 評価領域 | 提案配点 | 採点証拠 |
|---|---|---|
| プル・例外への業務適合 | 25 | 現場シナリオと状態履歴 |
| 連携・データ整合性 | 20 | 障害注入、重複排除、照合 |
| 現場操作・多言語 | 15 | タイ人作業者の実機完遂 |
| オフライン・復旧 | 15 | 停止・縮退・復旧の証拠 |
| セキュリティ・監査 | 10 | 権限、ログ、構成、運用 |
| 保守・拡張・移行性 | 10 | SLA、版、データ搬出、変更 |
| TCOの透明性 | 5 | 前提付きの初期・継続費用 |
| 合計 | 100 | 提案値。自社で再配分する |
TCOは、数量、単価、導入期、定常期、更新年、拠点増加時に分けます。効果側も「在庫削減率」のような根拠のない一値を置かず、緊急便、欠品停止、探索、手入力、照合、カード再発行、差異調査など、自社で観測できる時間・件数・金額に分解します。効果は現状値、PoC値、算式、測定期間、除外条件をセットで残します。
FAT・SAT受入ケース｜画面ではなく証拠の連鎖を見る
FATでは、設定・連携を安定した環境で検証し、SATではタイ工場の実ネットワーク、端末、設備、ルート、シフト、作業者で確認します。名称や範囲は契約に合わせますが、少なくとも次のケースを用意します。
| テストケース | FATで確認 | SATで確認 |
|---|---|---|
| 正常な補充一周 | 状態・メッセージ・監査 | 実容器・実ルート・実作業者 |
| 二重読取 | 冪等性と警告 | 複数端末・電波遅延下の動作 |
| 欠品・品質保留 | 割当拒否、例外遷移 | 現場の代替・承認・表示 |
| 取消・再発行 | 元信号との関連 | 現物回収と旧ラベル統制 |
| 通信断 | キュー、競合、再送 | 死角、切替、手作業、復旧 |
| ERP・WMS停止 | バッファ、監視、再同期 | 運用連絡と再開順 |
| 権限外操作 | 拒否と監査ログ | 共用端末、交代、退職者停止 |
| ピーク | 提案件数で負荷試験 | 実際の集中時間帯で操作 |
| バックアップ復元 | データ・設定の復元 | 業務再開と未処理照合 |
提案件数や応答時間は、現状観測とピーク設計から決めます。「常に2秒以内」といった根拠のない閾値は置きません。発行操作、一覧更新、ラベル、連携、復旧など場面ごとに、測定点、母数、百分位、許容例外を定義します。
受入証拠パックには、要件・テストの対応表、構成版、マスタ版、端末・ラベル版、入力・期待・実績、ログ、実行者、時刻、差異、是正、再試験、承認を含めます。監査ログがあるだけでなく、要求から到着、在庫・生産の後続処理まで相関IDで追えることを確かめます。
ライン供給 自動化へ広げる順序
電子カンバンを導入したからといって、すぐにAGV、AMR、自動倉庫、設備へ直接指示を出す必要はありません。まず人の運搬で信号品質と例外を安定させ、その後、搬送タスクへの変換、ルート割当、設備インターロックを段階的に追加します。
自動化では、電子カンバンの「補充要求」と、搬送システムの「実行タスク」を分けます。一つの要求を複数搬送へ分割する、一便で複数要求をまとめる、設備障害で人手へ切り替えることがあるためです。要求ID、タスクID、容器IDを関連付け、どの時点で責任が移るかを決めます。
段階展開の提案例は、①一ライン・一シフト、②同ライン全シフト、③隣接ライン、④複数棟、⑤外部サプライヤー、⑥搬送自動化です。各段階で、未解決重大障害がない、照合できる、手作業へ戻せる、現場教育が完了した、といったゲートを設定します。段階数や期間は提案値であり、自社の相互依存に合わせて変更します。
稼働後30・60・90日ゲート｜すべて提案値として運用する
本番後の30・60・90日は提案するレビュー時点です。法令や外部標準で決められた期限ではありません。
- 提案30日ゲート：未確認、長時間滞留、二重読取、手作業票、連携失敗、差異の上位原因を潰す。
- 提案60日ゲート：容器数、巡回、ルート、警告、権限、教育、保守手順を実績で調整する。
- 提案90日ゲート：次ライン・次拠点への展開、条件付き継続、再設計、中止を証拠で決める。
判定には、対象範囲、測定期間、母数、除外、基準線、目標、実績、残課題を併記します。たとえば「未確認信号を減らす」という目標なら、未確認の定義、業務時間、緊急信号、計画取消を分けます。数値を出すことより、同じ算式で比較できることが重要です。
また、変更管理を運用へ組み込みます。ERP・WMS・MESの版、Edge設定、端末OS、アプリ、プリンタ、ラベル、無線、権限、マスタは相互に影響します。変更前に代表シナリオと通信断復旧を再試験し、配布順、停止条件、戻し方を定めます。
よくある失敗と回避策
紙カードをそのまま一対一で画面化する
紙で暗黙に行われていたまとめ運搬、先行判断、緊急連絡が欠落します。現状を歩き、通常・例外・障害の状態遷移として再設計します。
電子カンバンに在庫台帳を持たせすぎる
ERP・WMSと数量がずれ、誰も直せない状態になります。信号状態と在庫状態を分け、調整権限と照合時刻を決めます。倉庫側の設計はタイWMS導入ガイドも参考になります。
リアルタイム連携だけを成功条件にする
正常時の速さは分かっても、遅延・重複・欠落・逆順で在庫や信号が壊れないか分かりません。障害注入と相関IDによる照合を受入条件にします。
紙フォールバックを禁止する
通信断で工程が止まるか、非公式なメモが生まれます。一意な仮IDと承認を持つ管理された手作業を定め、復旧後の照合まで試験します。
ダッシュボードを個人監視へ使う
数字を良く見せる行動を誘発します。工程、ルート、信号、マスタ、供給能力の改善を主目的にし、個人データの利用目的と権限を整理します。
PoCで正常系だけを見せる
本番で問題になるのは、欠品、品質保留、代替、通信断、誤ラベル、計画変更です。失敗を意図的に起こし、安全に止まり、戻り、照合できることを確認します。
電子カンバン導入チェックリスト
RFP前
- [ ] 現物、在庫、信号の三つの真実を分けた
- [ ] 発行・数量・供給元・先・確認・例外・監査を定義した
- [ ] 紙の一周を通常・例外・障害で観察した
- [ ] ERP・WMS・MES・Edge・電子カンバンの正本を決めた
- [ ] 容器、品目、場所、物流単位の識別ルールを決めた
- [ ] 通信断中の継続・条件付き継続・停止を決めた
- [ ] タイ語画面、ラベル、教育、現地支援を要件化した
- [ ] 要件ごとに証拠、採点、PoCケースを付けた
提案90日PoC
- [ ] 基準線の定義、母数、測定期間を固定した
- [ ] 実品目、実容器、実ルート、実作業者で試した
- [ ] 重複、遅延、逆順、取消、再送を試した
- [ ] 欠品、品質保留、代替、端数、緊急を試した
- [ ] 通信断、端末故障、プリンタ停止、連携停止を試した
- [ ] 手作業記録を復旧後に照合した
- [ ] 重大失格条件を加点で相殺していない
本番展開
- [ ] 範囲ごとに在庫と信号の正本を一つに固定した
- [ ] 切替、縮退、停止、ロールバック責任者を決めた
- [ ] 受入証拠と未解決課題を承認した
- [ ] 提案30・60・90日ゲートの判定者を決めた
- [ ] 次ライン・次拠点へ進む条件を明文化した
- [ ] データ搬出、契約終了、保守期限を確認した
FAQ｜電子カンバンと関連システムの疑問
電子カンバンとは紙カードをなくすシステムですか？
紙を減らすことは結果の一つですが、本質ではありません。発行契機、数量、供給元・先、確認、例外、監査を状態遷移としてつなぎ、重複や通信断でもプルのループを壊さない仕組みです。安定した小規模ループでは紙を残す判断も合理的です。
かんばん方式 システム化はどの工程から始めるべきですか？
重要度が高すぎず、代表的な例外があり、供給元・先と責任者が明確な一ループが適しています。最も簡単な工程だけではリスクを検証できず、最も複雑な全社ループでは原因を切り分けにくくなります。
作業指示 システムと電子カンバンの違いは何ですか？
作業指示システムは広く生産・物流タスクを割り当てます。電子カンバンは、後工程の消費などを契機に前工程へ補充を要求するプルループへ焦点を当てます。ただし実装では、電子カンバン信号から物流作業指示を生成するため、IDと責任境界の連携が必要です。
在庫管理 見える化のために電子カンバンだけを見れば十分ですか？
十分ではありません。電子カンバンは信号の滞留を示せますが、在庫の利用可能性、品質保留、引当、実地差異はERPやWMSが正本の場合があります。信号、在庫、現物を同じ時点で照合するビューが必要です。
ライン供給 自動化ではRFIDやAGVが必須ですか？
必須ではありません。バーコードと人のミルクランで十分な場合もあります。RFIDは一括・非接触読取に価値がある場合、AGV・AMRは安定した搬送タスクと安全な例外処理を作れる場合に検討します。技術を先に決めず、ループと受入条件から選びます。
90日PoCで効果を保証できますか？
できません。90日は本稿の提案枠であり、成功保証ではありません。自社の基準線と本番相当条件で、高リスク仮説を検証し、展開・条件付き展開・再試験・中止を判断するための証拠を作る期間です。
BOIの優遇を前提に投資してよいですか？
いいえ。公式資料には条件付きの対象区分がありますが、個別案件の適格性は活動、投資、申請時期、証拠、最新制度で変わります。BOIおよび専門家へ確認し、優遇がなくても成立する事業性と分けて評価してください。
まとめ｜電子カンバンは信号・在庫・現物を照合できて初めて定着する
電子カンバン導入の成否は、カードを画面に変えた数では決まりません。プルの発行契機、数量、供給元・先、確認、例外、監査を閉ループとして定義し、信号の正本と在庫の正本を分け、現物と照合できることが必要です。紙が適する安定工程は残し、複数棟、変動、紛失、遠隔監視、監査の課題が大きいループから電子化します。RFPは受入試験の原型とし、提案90日PoCでは通常系よりも重複、通信断、欠品、品質保留、復旧を試します。証拠がそろった範囲だけ段階的に展開することが、タイ工場で止めずに定着させる近道です。
TOMAS TECHでは、製品が未決定の構想段階から、現状ループの可視化、ERP・WMS・MESとの責任分界、RFP、タイ語を含むPoC、FAT・SATの証拠設計まで支援しています。紙かんばんを残す範囲の判断や、一ラインだけの検討段階でも、お問い合わせからご相談いただけます。
参考情報
- Toyota Motor Corporation, Toyota Production System: https://global.toyota/en/company/vision-and-philosophy/production-system/
- Toyota Motor Corporation, Virtual Plant Tour / Pull System: https://global.toyota/en/company/plant-tours/production-system/
- ISA, ISA-95 Standard: https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard
- GS1, How GS1 standards work: https://www.gs1.org/standards/how-gs1-standards-work
- GS1, Identification keys: https://www.gs1.org/standards/id-keys
- GS1, Barcodes: https://www.gs1.org/standards/barcodes
- OPC Foundation, OPC UA Part 1 Overview: https://reference.opcfoundation.org/specs/OPC-10000-1/4
- Thailand Board of Investment, Measure for Industrial Upgrades towards Smart and Sustainable Industry: https://www.boi.go.th/upload/content/Smart_and_Sustainable_Industry.pdf
※本稿は2026年9月8日時点の公開情報に基づく一般的な実務整理です。90日PoC、30・60・90日ゲート、配点、しきい値、段階、テスト件数は提案例であり、法的要件、外部ベンチマーク、効果保証ではありません。制度・契約・セキュリティ・投資判断は、貴社の責任者および専門家と確認してください。
