製品開発を外注する際、仕様どおりに動作する試作品を完成させることは重要ですが、それだけで市場投入後の品質を支えられるとは限りません。出荷前の評価では見つからなかった不具合が、長時間運転、設置環境の変化、利用者の操作、部品の経年変化などをきっかけに発生することがあります。そのとき、現場から「突然停止した」「ときどき通信できない」という報告だけが届いても、原因を絞り込むのは困難です。
不具合を再現できないまま部品交換やソフトウェア修正を繰り返すと、真因が残り、同様の症状が別の個体で再発する可能性があります。こうした手戻りを減らすには、製品がどのような状態で、何をきっかけに異常へ至ったのかを追跡できるログの設計が欠かせません。ログは開発者の確認用メッセージではなく、市場で起きた事象を製造履歴や設計変更に結び付ける品質情報として扱う必要があります。
本記事では、「製品開発 外注」で委託先を探している企画・設計・品質保証担当者に向けて、市場不具合の原因調査に役立つ5つのログ記録設計と、外注先との仕様合意、検証、運用の進め方を解説します。
製品開発の外注でログ記録設計が重要になる理由
外注による製品開発では、委託先が回路設計、組み込みソフトウェア、筐体、通信機能などの一部または全体を担当します。発注側は要求仕様や受入試験をまとめ、委託先はそれに従って成果物を作ります。この分業自体には利点がありますが、市場で発生した異常について、どの情報を残すべきかが契約や仕様に含まれていなければ、原因調査に必要な情報が最初から記録されていないことがあります。
例えば、現場の機器が予告なく再起動したケースを考えます。「再起動しました」という記録だけでは、電源電圧の低下、ソフトウェアの停止、過熱、外部からの操作、正常な更新処理のどれが契機だったのか判断できません。再起動直前の電源状態、処理の異常検知、温度、起動理由などが関連付けて保存されていれば、疑うべき原因を段階的に減らせます。ただし、すべての原因をログだけで特定できるわけではなく、実機の測定や部品解析と組み合わせることが前提です。
開発中は担当者が測定器を接続して動作を観察できます。一方、市場に設置された製品は、同じ環境を開発室に再現できるとは限りません。通信状態や電源設備、作業順序、周辺温度が日によって変わるからです。したがって、限られた容量の中で、通常時の特徴と異常時の前後関係を判断できる情報を優先して残す考え方が有効です。
また、ログを大量に出力することが必ずしも調査効率につながるとは限りません。重要なイベントが埋もれたり、記録処理自体が動作を妨げたり、保存領域が早期にいっぱいになったりする可能性があります。何を記録するかだけでなく、何を記録しないか、どの条件で詳細記録へ切り替えるか、いつ削除するかまで設計する必要があります。
発注側が重視したいのは、機能の実装可否だけでなく、市場で問題が生じた場合に自社と委託先が共通の情報を使って原因を調査できる状態です。調査可能性を開発成果物の品質要件として明確にすることが、長期運用を前提とする外注では重要になります。
設計1：製品個体と変更履歴を結び付ける識別ログ
最初に設計するのは、異常が起きた個体が何者で、どのような構成で動いていたかを特定するための識別ログです。同じ製品名で出荷されていても、製造時期や調達ロットによって使用部品が変わったり、出荷後の更新でソフトウェアの処理が変わったりします。この違いが分からないと、不具合が特定の部品、製造期間、ソフトウェア版に集中しているかを調べられません。
基本となるのは、製品の個体識別子、ハードウェアの改訂番号、ソフトウェアのビルド識別子、設定情報の版、製造ロットなどを一貫した形式で扱うことです。製品本体に付けた識別子と製造記録の識別子が対応している必要があります。外注先の内部でしか通用しない番号だけで管理すると、委託契約の終了後に発注側が履歴を読み解けなくなるおそれがあります。番号体系の意味と管理責任を仕様書に残すことが重要です。
識別情報は、起動時の記録に含めるだけでなく、調査用にログを取り出した際にも確認できるようにします。ログファイルが単独で共有された場合でも、どの個体の、どの構成の記録か判断できることが望まれます。ただし、個体番号だけをファイル名に含める方式では、取り違えや名前の変更が起き得ます。ファイル内部にも識別情報と記録形式の版を持たせると、後から照合しやすくなります。
変更履歴は特に重要です。ソフトウェア更新の開始、成功、失敗、更新前後の版、設定値の変更、初期化操作などをイベントとして残せば、不具合の発生時期と変更時期の関係を調べられます。例えば、通信が途切れる症状が更新後に増えたとしても、更新自体が原因とは限りません。更新を受けた個体群と受けていない個体群の条件をそろえて比較するために、正確な履歴が必要になるのです。
設定値については、すべてを無条件に記録するのではなく、動作を左右する項目を選びます。校正値、制御の閾値、通信周期、電源管理の設定などは、異常に関係することがあります。機密情報や認証用の秘密情報をログに直接書き込まないことも不可欠です。設定の内容を記録できない場合は、安全な照合用識別子や設定版で変更の有無を確認できるようにします。
外注先には、識別子の生成方法、重複防止、書き換え権限、製造工程での登録方法、修理や基板交換時の扱いを確認します。主基板だけを交換したときに製品の識別子を維持するのか、新しい識別子との対応履歴を残すのかも決めておきます。修理を境に個体の履歴が断絶すると、継続使用による劣化と交換後の問題を区別しにくくなるためです。
この設計の成果は、ログに番号を印字することではありません。異常の記録を製造、試験、出荷、更新、修理の履歴へたどれることです。調査の入口となる識別情報が安定していれば、同じ症状が発生した個体を抽出し、影響範囲を検討するための基礎が整います。
設計2：異常前後の順序を再現する時刻・イベントログ
二つ目は、異常が起きるまでの出来事の順序を再現する設計です。市場不具合では「いつ発生したか」だけでなく、「何が先に起きたか」が原因の切り分けを左右します。通信断の後に制御が停止したのか、制御が停止した結果として通信が途切れたのかでは、調べるべき箇所が変わります。イベントを時系列に並べられることは、再現が難しい不具合ほど重要です。
記録対象としては、電源投入、起動完了、動作モードの変更、外部機器との接続と切断、通信の再試行、異常検出、保護動作、停止要求、再起動などが考えられます。すべての内部処理を毎回記録するのではなく、状態遷移の節目と異常に関連する操作を優先します。イベントには共通の識別コードと重要度を割り当て、同じ意味の事象が複数の場所で別名として出力されないようにします。
時刻は単純に現在時刻を付ければ足りるわけではありません。製品によっては、電源投入直後に時計が未設定であったり、時刻補正により表示上の時刻が前後したりします。そのため、日時と併せて起動からの経過時間や単調に増える計数値を記録する方法が有効です。絶対時刻が不正確でも、同一起動期間内の前後関係を読み取れるようにするためです。再起動ごとに起動識別子を持たせれば、計数値が初期化されても記録の区切りを把握できます。
複数の制御基板や外部装置が連携する製品では、機器ごとの時計のずれや通信の遅延にも注意します。別々の装置に付いた時刻が一致しているように見えても、厳密な順序が保証されるとは限りません。必要に応じて、メッセージの送信と受信、処理要求と結果を対応付ける識別番号を記録します。時計の同期方法、同期できなかった期間、推定される時刻の信頼度も調査資料になります。
異常の直前を調べるためには、一定期間のイベントを循環記録し、重大な異常を検出したときに前後の情報を保存する方法が考えられます。ただし、異常後の記録を増やすことで直前の情報が上書きされてしまっては意味がありません。保存対象の前後時間、異常時の記録停止条件、再起動後の保護方法は、実際に発生し得る事象に合わせて決めます。
例えば、再起動が連続する現象では、起動直後の詳細記録ばかりが保存され、最初の異常を示す情報が消えることがあります。初回異常の概要を別領域に保持し、その後の再起動回数を集計する構成であれば、原因に近い証拠を残せる可能性があります。一方、すべての機器に同じ保存方式が適しているわけではありません。容量、書き込み速度、製品の動作周期に応じて検討する必要があります。
外注先との受入確認では、意図的に通信断や再起動を発生させ、記録の並びを確認します。時刻情報が欠けた場合でも最低限の因果関係を判断できるか、イベントコードの説明書から意味を解釈できるかまで確認すると、ログが実際の調査に使える状態へ近づきます。
設計3：原因を切り分ける状態量・環境・操作ログ
三つ目は、異常の背景を説明できる状態量を残す設計です。イベントログが出来事の順序を示すのに対し、状態量のログは「その瞬間、製品がどのような条件で動いていたか」を補います。過熱、電源変動、通信品質の低下、機構部の負荷、設定の不整合など、異なる原因で似た症状が出る製品では特に役立ちます。
どの項目を残すかは、製品の故障の起こり方から逆算して決めます。電源が不安定になる可能性があるなら、検出可能な範囲で電源電圧、保護回路の状態、電源切替の履歴などを候補にします。熱に関係するなら、センサーの設置位置を明記した温度や、出力制限が働いた事実を残します。通信が重要なら、接続状態、再送回数、応答待ちの時間超過、受信品質の指標などを検討します。存在しないセンサーの値を推定値として断定的に扱わず、実測値か計算値かを区別することも大切です。
記録間隔には注意が必要です。短い電圧低下や瞬間的な負荷変動は、数秒ごとのサンプリングでは取り逃す場合があります。しかし、常時高速で全項目を保存すると、処理負荷や記憶容量、書き込み寿命に影響します。通常時は要約値や周期的な記録にとどめ、異常の兆候が出たときだけ詳細度を高めるなど、段階的な設計が現実的です。最小値、最大値、平均値を一定区間で集計する方法もありますが、瞬間的な波形そのものを復元できるわけではないため、目的に応じて使い分けます。
利用者の操作も原因調査の手掛かりです。操作によって設定や動作モードが変わる製品では、どの操作種別が受け付けられ、どの処理結果に至ったかを記録します。ただし、操作履歴を詳しく残せば残すほどよいとは限りません。氏名、入力内容、位置情報などが不要であれば取得せず、必要な場合も利用目的、閲覧権限、保存期間を明確にします。技術的な調査に必要なイベントと、個人を特定し得る情報は切り分けて扱うことが望まれます。
重要なのは、数値だけでなく単位と計測条件を揃えることです。温度の記録であれば、どの測定位置の値なのか、どの範囲まで精度が期待できるのかが分からなければ比較できません。通信品質の数値も、算出方法が版によって変わると時系列の比較を誤る可能性があります。ログ形式には項目名、単位、値の範囲、欠測時の表現、更新周期などを定義しておきます。
異常時の状態を一括して記録する仕組みも有効です。例えば、制御が安全停止に移ったときに、直前の動作モード、主要な入力値、保護状態、直近のエラーコードを同じイベント識別子でまとめます。別々の周期で集めた値を同時刻の計測と誤認しないように、各値の取得時刻や鮮度を示すことも必要です。
市場で報告される現象を想定し、委託先と「このログがあればどの仮説を否定できるか」を確認すると、項目の取捨選択がしやすくなります。すべてを記録するのではなく、主要な故障仮説を識別するために必要な状態量を確保することが、実用的な設計につながります。
設計4：電源断や通信障害に備える保存・保全ログ
四つ目は、残したはずの記録が市場不具合の発生時にも利用できるようにする設計です。ログの項目が充実していても、電源断の際に消えたり、通信できないと取り出せなかったりすれば、肝心な場面で役に立ちません。保存媒体、書き込み処理、容量管理、取り出し経路まで含めて考える必要があります。
特に確認したいのは、記録の確定タイミングです。動作中の情報を一時的なメモリに保持してから不揮発性の保存領域へ書き込む構成では、突然の電源断によって最新部分が失われる可能性があります。一方、重要な値をすべて即時に書き込むと処理遅延や媒体の消耗を招く場合があります。重大な異常と通常の動作情報で保存優先度を分け、許容できる記録欠落の範囲を仕様として合意します。
保存形式については、書き込み途中で停止した際に、どこまでが正常な記録か判定できるようにします。記録ごとの長さ、連番、検査値などを利用すれば、途中で欠けたデータを検知しやすくなります。ただし、検査値が一致することは、内容が事実であることまで保証しません。意図しない破損の検出と、不正な書き換えに対する保護は分けて設計する必要があります。用途や脅威に応じて、アクセス制御、暗号化、改ざん検知などの対策を検討します。
容量管理では、保存領域がいっぱいになったときの動作をあらかじめ決めます。古い通常ログから削除するのか、異常記録だけ別枠で保持するのか、未回収の記録をどれだけ守るのかによって、調査に残る証拠が変わります。長期運転機器では、繰り返し書き込みによる記録媒体への負荷も無視できません。想定稼働年数、記録頻度、書き込み量に基づいて媒体の選定と耐久評価を行う必要があります。
通信機能を持つ製品でも、常時接続を前提にした保存は避けたいところです。現場の通信断やサーバー側の障害が起きても、必要な記録を機器内部に一時保持し、復旧後に重複や欠落を判定しながら送れる設計が考えられます。送信に成功したか、相手側で受領されたかは別の状態です。確認応答と再送の仕様を定義し、同じ記録が複数回届いても分析で重複計上しない仕組みが求められます。
一方、外部へ送らずに現場で回収する製品では、接続端子や保守操作でログを取得できるか、故障状態でも取り出せるかを検討します。通常の利用者が誤って削除できないようにしながら、正当な保守担当者が手順に従って取得できる設計が理想です。取得操作によって元のログが変更される場合は、何が変わるのかを明らかにし、必要に応じて原本を保護します。
ログは情報資産でもあります。製品仕様や内部構成、利用状況を推測できる情報が含まれる場合があるため、誰が閲覧できるか、委託先にどの範囲で提供するか、いつ削除するかを定めます。保存の信頼性と情報保護を両立させてこそ、市場で継続して使えるログ基盤になります。
設計5：現場回収から是正までつなぐ運用ログ
五つ目は、記録した情報を不具合対応の業務へ確実につなぐ設計です。製品内部に十分なデータが残っていても、現場で取得する手順が難しい、問い合わせ票と個体番号が結び付かない、委託先が形式を解読できないといった状態では、調査開始までに時間がかかります。技術的なログ設計と併せて、誰がどの情報を回収し、何を判断するのかを決めておく必要があります。
最初に、市場から不具合報告を受けた際の受付情報を統一します。発生日時、製品の個体識別子、症状、利用中の動作モード、直前の操作、復旧方法、再発状況などを、取得可能な範囲で記録します。現場担当者に原因を推測して書いてもらうより、「どの表示が出たか」「再起動で復旧したか」といった観察事実を集める方が分析には役立ちます。聞き取りで得た情報と機器内部のログを区別し、後から対応付けられるようにします。
調査案件ごとに識別子を割り当て、受付情報、回収ログ、現場写真、修理履歴、検証結果、設計変更を結び付ける運用も有効です。同じ個体で複数の不具合が起きた場合でも、案件を分けて整理できます。逆に、複数の個体で同じ根本原因が疑われる場合は、横断的に検索できる分類体系が必要です。症状名と推定原因を混同せず、調査段階に応じて分類を更新できる形が望まれます。
ログの取り出し手順は、現場の制約を前提に設計します。設置済み機器を簡単に取り外せない、電波が届かない、停止可能な時間が限られるなど、開発室とは条件が異なるためです。取得作業の所要条件、操作に必要な権限、製品動作への影響、取得に失敗したときの代替方法を文書化します。記録を回収するために再起動が必要な場合は、その操作で失われる情報がないか事前に評価しておきます。
ログを解析する側にも準備が必要です。イベントコードと説明の対応表、記録形式の版管理、日時や数値の解釈方法、異常パターンの検索手順などを、委託先の担当者だけに依存しない形で残します。調査用の解析ツールを外注先が作る場合は、その実行環境や保守範囲、必要な権利、引き継ぎ資料を成果物として扱うことが重要です。特殊な環境がないと読み取れない形式にすると、将来の委託先変更時に調査が難しくなります。
運用ログには、調査の判断過程も含まれます。どの現象を確認し、どの仮説を検証し、何を根拠に否定したかを残すことで、同様の問い合わせが生じた際に対応を再利用できます。暫定的な対処と恒久的な是正を分け、変更後の検証結果と市場での再発状況まで追跡することで、単発の修理対応を設計品質の改善につなげられます。
なお、ログに記録がないことをもって「その事象が発生していない」と断定するのは危険です。通信障害や容量不足、電源断、記録条件の不一致で残らなかった可能性があります。解析結果には記録範囲と欠測の有無を示し、追加測定や現品調査が必要か判断する姿勢が欠かせません。
ログ仕様を外注先と合意するための進め方
ログ記録設計を実効性のあるものにするには、製品の機能仕様と同じように、発注段階から要求を具体化することが大切です。「不具合解析に必要なログを実装する」という一文だけでは、委託先と発注側の想定がずれやすくなります。何の不具合を調べたいのか、どの状態を残したいのか、どれくらいの期間保存するのか、誰が回収・解析するのかを明確にします。
まず、過去の類似製品や想定用途から、重大な故障と発生しやすい症状を整理します。停止、誤動作、測定値の異常、起動不能、通信断、設定消失などについて、原因候補と必要な観測情報を対応付けます。この作業には回路、ソフトウェア、機構、品質保証、保守の担当者が参加すると、特定の技術領域に偏りにくくなります。原因候補が複数ある現象から優先的に記録対象を選ぶと、限られた記憶容量を効果的に使いやすくなります。
次に、ログの項目定義書を作ります。イベントコード、項目の意味、単位、発生条件、保存先、重要度、記録周期、最大保存量、消去条件、取得方法、機密性などが対象です。発注側が要求水準を提示し、委託先が機器の能力や処理負荷に照らして実現方法を提案する進め方が適しています。実装困難な項目があれば、代替の検知方法や取得条件を協議し、設計判断の理由を残しておきます。
責任分担も曖昧にしないことが重要です。機器内での記録実装、記録形式の維持、解析手段の提供、障害時の一次切り分け、更新後の互換性確認、保守終了時の資料引き渡しについて担当を決めます。ログに含まれる情報の取り扱い、発注側が取得・利用できる範囲、外注先へ提供する際の保護措置も契約条件と整合させます。権利関係や秘密保持に関わる内容は、実際の契約に即して確認する必要があります。
受入条件は「ログが出力されること」より一段具体的にします。例えば、指定した異常を発生させた際に、対象イベントと直前の状態が取り出せること、時刻情報が未設定でも発生順序が分かること、複数回再起動しても指定した異常記録が維持されることなど、試験で判定できる形にします。異常を注入する方法と期待する記録も合わせて定義すると、開発後半での解釈の食い違いを防ぎやすくなります。
さらに、引き渡し時にはログ形式の仕様書だけでなく、実機からの取得手順、解析例、未知のイベントコードが出たときの取り扱い、更新時の互換性方針も確認します。委託先しか知らない内部情報を前提にした仕組みは、担当者交代や保守契約終了で使えなくなるリスクがあります。発注側が継続的に運用できる状態を、完成条件の一部に据えることが大切です。
市場不具合を想定したログ検証の進め方
ログの価値は、正常に動いているときではなく、想定外の状態に遭遇したときに表れます。したがって、通常の機能試験だけで記録機能を合格にせず、異常を意図的に発生させる試験を計画します。どの情報が残ったかに加え、その情報で原因の候補を絞れるかまで評価することが重要です。
電源に関する試験では、通常停止と突然の電源遮断を区別して実施します。電源が瞬間的に低下したときに機器の動作がどう変わるか、保存途中の記録がどう扱われるか、再起動後にどの情報が残るかを確認します。電源が失われる瞬間の記録は構造上残せない場合もあるため、保存方式の限界を把握し、必要なら事前の低電圧検出などを検討します。記録が存在しないこと自体を仕様上の既知の制約として整理しておくことも大切です。
通信に関する試験では、一時切断、長時間の切断、接続と切断の繰り返し、送信先の応答遅延を再現します。機器内のログが維持されるか、再接続後に送信が再開するか、重複データを識別できるかを確認します。送信先に到着した時刻と製品側で発生した時刻を混同せずに解析できるかも確認対象です。通信できない期間のデータが欠落している場合、機器側の保存不足なのか送信処理の問題なのかを区別できると調査が進みます。
長期動作の試験では、記録容量の上限、連続稼働時の処理負荷、保存領域の切り替え、更新後の互換性などを確認します。短時間の開発試験では問題なくても、通常ログが蓄積すると異常記録の保存枠を圧迫することがあります。異常が何度も続いた場合や、ログ回収が長期間行われなかった場合など、運用上の厳しい条件を用意して評価します。
調査の模擬訓練も効果的です。試験担当者が不具合の発生条件を伏せた状態でログを渡し、解析担当者がどこまで原因候補を絞れるかを確認します。必要な情報が欠けていれば、項目を増やすだけでなく、イベント名の曖昧さや取得手順の不備、解析説明書の不足を見直します。調査に時間がかかった理由を振り返ることで、実用性を高められます。
試験後は、ログの記録処理自体が製品に悪影響を与えていないかも確かめます。頻繁な書き込みによる応答遅延、割り込み処理との競合、記憶領域の不足などが起きると、調査のための仕組みが新たな不具合の要因になりかねません。記録を増やした状態でも、本来の制御、安全機能、必要な応答性能が維持されるかを確認します。
市場投入後も、調査で使えなかったログ項目や不足していた記録を振り返り、次回更新や次期製品の仕様に反映します。ただし、ログ形式の変更が既存の解析を壊さないよう、版管理と変換方針を設けることが必要です。記録項目を追加する場合にも、保存容量と情報保護の条件を再評価し、無制限な拡張を避けます。
まとめ：原因追跡できる設計を開発仕様に組み込む
製品開発を外注するとき、市場不具合への備えは出荷後の保守体制だけで決まるものではありません。異常が発生したときの手掛かりをどれだけ残せるかは、開発初期の設計判断に大きく左右されます。個体と変更履歴をつなぐ識別ログ、出来事の順序を示す時刻・イベントログ、原因候補を切り分ける状態量のログ、記録を失わないための保存・保全の仕組み、そして現場回収から是正につなげる運用の5つを一体で考えることが重要です。
外注先を選ぶ段階では、機能の実現力だけでなく、障害時に何を記録し、どのように回収・解釈するかを説明できるか確認しましょう。発注側も、想定する故障や調査の流れを共有し、ログの項目定義、受入試験、引き渡し資料、責任分担を具体的にしておく必要があります。これにより、原因を断定できない状況でも、仮説と事実を切り分けながら調査を前進させやすくなります。
特に屋外設備や施工現場で使う製品では、機器内部のログだけでは周囲の状況を十分に説明できないことがあります。設置状況、現場での作業内容、異常発生時の外観などを写真と位置情報で残し、機器の個体識別子や発生日時と対応付けると、調査資料として活用しやすくなります。その際は、位置情報の取得目的や関係者の情報保護にも配慮が必要です。
現場写真・位置情報・施工記録を管理する自社プロダクトのLRTK Phoneは、こうした現場側の状況を記録する場面で活用を検討できます。機器内部のログとは役割が異なるため、両者が自動で連携することを前提にせず、個体番号や案件番号を用いて照合できる運用を整えることがポイントです。製品の動作履歴と現場の記録をそれぞれ確実に残すことが、市場不具合の調査を支える実践的な第一歩になります。
ものづくりの次の一歩を、
相談から始めてみませんか。
加工・製造の外注先や共同開発のパートナー探しに。大田区産業振興協会の受・発注あっせん相談サービスをご利用いただけます。
