機械検査・別担当のレビュー・公開承認を分ける——変更した成果へ古い承認を流用しない
形式が合っていることと、外部へ送ってよいことは別の判断です。根拠を添えた確認画面、保留中の入力変更、承認対象の版を持つ業務フローを考えます。機械検証と別担当の受入を分け、取り消せない操作の前に必要な判断材料をそろえます。
ENGINEERING JOURNAL
技術ブログ
AIに仕事を任せるための設計、システム連携、検証と運用。実装の背景にある判断を紹介します。
FFmpegで完成動画を検査する——映像・音声・字幕の対応と、変更による影響範囲を追う
素材が個別に正しくても、合成後の商品名や字幕時刻はずれることがあります。場面ごとの素材と採用区間を対応付け、FFmpegと関連ツール（ffprobe）による完成動画の検査と、説明内容・聴き取りの確認を分ける方法を考えます。架空商品の制作記録から、確認できる範囲も整理します。
ローカルの生成ツールComfyUIによる動画生成を完成まで測る——素材採用・修正・合成・検査の計測設計
素材の生成が速くても、採用できず作り直せば完成は遅れます。生成、採用判断、修正、合成、検査の時間を分けて測る設計を考えます。ComfyUIの素材を使う36秒の無音試作と、架空の商品を使ったCM・解説本編の制作記録は、確認した範囲が異なります。
要点と根拠を分けて見せる比較画面——Web画面とGoogleスライドで条件の欠落を検査する
短い比較表で、見積の例外や休業条件まで判断できるでしょうか。要点・未確認・詳細を分ける拠点改修の画面設計を考えます。Web画面から編集可能な資料へ移す場合も、文字の一致と配置の意味を別に検査し、条件と拠点の対応を保ちます。
n8n・Difyの模擬の一連の試験から本番へ進む条件——接続・AI判断・外部操作を別に検証する
実サービス同士が連携しても、モデルを呼ばず模擬結果を返す範囲では実AI品質は分かりません。模擬の受注処理で、応答が届かない・同じ依頼が二重に届く・途中で入力が変わる場合を試し、実データの参照、判断確認、限定した外部操作へ段階を進める設計を考えます。接続試験と実取引の成功を分けて評価します。
PostgreSQLの書き足すだけで消さない履歴（追記型履歴）で試行と受領を分ける——入力版・検査・採用理由を追跡する
送信を試した記録と、相手側が受け付けた記録は別です。月次通知の入力版、配信試行、受領、検査、採用を分け、相手からの応答が途切れた場合と訂正を追える履歴の設計を考えます。追記する履歴と工程の保存状態を対応付け、どの本文が承認され、配信されたかを確かめます。
担当の割り当てと遅れた提出を分ける——期限切れ・引継ぎ・二重処理の検証設計
返事がない担当へ渡した請求書を、すぐ別担当へ振り直してよいでしょうか。予約の証拠、入力版、期限切れ後の照会、古い担当の提出拒否を持つ請求書確認の設計を考えます。進行状態の保存と実行履歴を分け、切替前に成果と外部操作の有無を確かめます。
複数AIの調査を並列化する——出力形式の取り決めと根拠の照合で比較資料へ統合する
三つのAIへ同じ問いを渡すだけでは、重複や異なる基準の回答が増えます。会社別の調査、共通の出力項目、統合時の保留と追加確認を分ける取引先比較の設計を考えます。並列に集めた結果は個別に保存し、根拠を照合してから一つの資料へまとめます。
データ項目を段階移行する——新旧区分の併存・書き込み経路・元に戻す手順（ロールバック）の設計
申請区分を増やしても、既存の集計や承認画面が読めなければ更新は完了しません。新旧の意味と版、共通の書き込み経路を定め、先に新旧を読める状態へ整える移行設計を考えます。変更後に受け付けた申請も含めて差戻しを試すことが、復旧の条件になります。
原文・抽出値・業務判定を三層で保存する——条件付き数値の根拠と訂正を追う
「停止直後に八十度」と「運転中に八十度」を同じ値として扱うと、判定を誤ります。報告の原文・抽出値・判定基準を分け、原文の版と該当箇所へ戻れる設備報告の設計を考えます。訂正や否定文を含む検査で、数値と条件の取りこぼしを別々に確かめます。
データ収集と読み取り専用配信を分離する——検査済みの版だけを閲覧へ渡す
在庫一覧を開くたびに仕入先へ問い合わせる構成では、閲覧の増加が収集へ波及します。収集・蓄積・配信を分け、更新候補の検査、版の切替、古さの表示、同じ更新依頼の集約を設計する方法を考えます。収集停止と同時閲覧を別の試験にすることが、分離の確認に役立ちます。
欠落値・ゼロ・更新遅延を分ける一覧設計——対象時点と集計の対象範囲を保存する
未取得をゼロに変換すると、配送件数も平均も誤った意味になります。値・確認状態・対象時点を保持し、古い値が後から届いた場合や収集が止まった場合を検査する配送一覧の設計を考えます。データの保存側とWebの表示側で同じ状態の意味を共有することが、利用者の判断を支えます。
複数情報源の売上データを統合する——単位・期間・出所と網羅性を検査する
出荷・入金・受注の金額は、同じ支店の数字でも足せません。支店売上の比較単位と対応表を定義し、速報と確定の食い違い、単位の違い、欠けた支店を見つける統合設計を考えます。Pythonでの取得・検査とデータベースの保存を分け、採用値から元資料へ戻れる関係を残します。
自動修正を元資料・変更案・保存結果で照合する——不一致と結果不明を分ける
修正の返答と、保存先に残った値が同じとは限りません。帳票の元資料・変更案・再取得した保存結果を照合し、反映の遅れや他担当の変更を調べてから再修正を判断する設計を考えます。修正担当と確認担当を分け、根拠と未確認事項を一緒に渡します。
Pythonとブラウザ自動操作で月次事務を分担する——分類・修正・起票後の照合
月次の分類・修正・起票では、入力の不足、変更理由、登録後の照合をどうつなぐかが重要です。Python・pydantic・pytestとブラウザ自動操作を使う医療系業務代行でヤクモが提供した実装を参考に、取り消せない操作を人へ残す工程設計を考えます。
APIとブラウザ自動操作を比較する——権限・対象照合・保存結果で接続を選ぶ
APIがあるかどうかに加え、保存結果を再取得できるか、応答を失ったときに照会できるかが接続選択を左右します。担当者が確認した申請を登録する場面を例に、APIと画面操作の権限・変更への対応・結果不明時の経路を比較します。
AI申請フローの例外分岐を設計する——情報不足・接続失敗・結果不明の再開条件
申請の添付不足と、登録を依頼した後に返事が届かなかった場合を同じ「失敗」にすると、再送の判断を誤ります。不足・対象外・接続失敗・結果不明で返す先を分け、引継ぎ情報と再試行上限を持つ申請整理の設計を考えます。LangGraphの分岐とSQLiteの状態保存を、再開の条件へ結び付けます。
n8n・Difyの連携の概念実証（PoC）を段階ごとに評価する——受付・状態・結果とAI品質を分ける
n8nからDifyへ接続できたことは、AIの判断品質を確認したことになるでしょうか。AIモデルを呼び出さずに模擬の結果を返す連携の試作（PoC）を例に、受付・状態・結果取得・重複依頼の契約を整理します。実AI処理へ進む前に、続行・中止・条件変更の判断材料をそろえる設計を考えます。
仕様書（OpenSpec）の受入条件を実装検査へつなぐ——仕様・決めた検査項目・変更後の照合
申請文から回答候補を作れても、仕様が整っただけでは開発完了にできません。OpenSpecで受入条件を整理し、LangGraphを使い、決めた検査・別担当のレビュー・再照合へつなぐ設計を考えます。設備申請の正常・不足・対象外を例に、仕様を検査可能な条件へ変えます。
経費資料のAI分類を一工程で試す——入力・根拠・確認待ちを分ける設計
領収書の読み取りと分類候補を、正式登録から切り離すには何が必要でしょうか。作業・検証・受入を分け、正常な資料、情報不足、重複にそれぞれ結果を定める経費分類の設計を考えます。候補の根拠と人へ返す条件をそろえることが、最初の試作の焦点です。
制作の品質確認を前提・成果物・利用条件へ分ける——目的と本文を照合する三段階の確認案
研修資料の誤字と配置が整っても、受講後の行動や使用範囲は別に確かめる必要があります。研修の設計情報も検査対象に加え、制作前の目的、制作後の本文と演習、使用前の表示と利用条件を分けて受け入れる方法を提案します。
AI依頼の入力検証を工程ごとに置く——必須・空白・未定を分けて再開する設計案
対象不明の見積依頼を、自然な文章だけで後段へ通さないための提案です。必須情報の欠落を止める検査として、存在・形式・妥当性を分離し、初期調査と見積確定で必須条件を変えます。不足の返却と入力変更後の成果の見直しまで説明します。
AIエージェントの許可リストを業務へ対応させる——参照・作成・更新・送信の設計案
契約照会の回答案を作るAIに、どの資料と操作を許すか。参照権限を事前に整え、対象と操作を組にした許可リスト、業務上の権限、正常例と拒否例の検査を整理します。接続できることだけで安全や導入効果を断定しません。
AIの誤操作を再発防止の確認へつなぐ——行動ログ・読み取り専用権限・入口検査の設計案
問い合わせを整理するAIが、顧客台帳まで更新してしまう誤操作をどう防ぐか。行動ログと保存先の変化を照合し、指示の追記、読み取り専用API、更新入口の検査を比較します。同じ入力条件と言い換えを使い、誤操作を止めながら許可された仕事を進められるかを検証する設計を考えます。
文章レビューとファクトチェックを分離する——数値・時系列・公開版を照合する設計案
読みやすい文章でも、処理時間や導入時期の根拠は別に確かめる必要があります。文章レビューと事実確認の責務を分離し、主張を検証単位へ分け、比較条件と一次記録へ照らし、修正後の見出しや図まで確認する工程を提案します。
AI入力補完を根拠付きデータへ限定する——台帳の値・欠損・人の確認を分ける設計案
商品名や価格は指定台帳から取得し、未登録とゼロと通信失敗を別状態で返す。経験や判断が必要な項目は人へ質問する。取得元、単位、承認後の差分を保持する入力補助の設計を考えます。
助言AIと実行担当をつなぐ——起動・保存・参照・情報が欠けたときの止め方を比べる設計案
契約変更の案内を例に、助言役の判断が文章担当へ届く接続を設計します。同じ問い合わせに二種類の助言を渡し、回答の意味が変わる条件を先に定めます。呼び出し、保存した判断、後の工程での参照、必要な情報が欠けたときの停止を分けて検証する方法を示します。
AIエージェントの責務と更新APIを分ける——申請変更を候補・登録・受入で追う設計案
希望日が変わる申請を例に、読み取り、確認、登録、受入の役割を分けた設計を考えます。読み取り担当は根拠付き候補、登録担当は確認済みの値と受付結果を返す構成です。更新APIの重複防止と結果照会を論点にし、登録先の仕様に応じた検査条件を示します。
n8n＋Dify＋SQLiteで模擬ジョブを接続する——結果を後から受け取るAPIと、二重受付を防ぐ仕組みの概念実証
実際のn8nとDifyを通して模擬の企画を渡し、SQLiteへ受付と状態を保存した概念実証です。受付APIが「受付済み」を返す応答（202）、同じ依頼番号で内容の違う依頼を拒否する応答（409）、意味上の失敗検査と状態照会を解説します。AIモデルは呼び出しておらず、本番の制作も行っていません。
記事・資料・動画の版をそろえる——入力の照合値と保存済みの素材で再制作を選ぶ
仕様の一文を直した後、資料や声に古い説明を残さないために何を照合するか。制作支援基盤で入力内容から作る識別値（指紋のようなもの）、ページごとの音声確認、絵コンテと、一度作った画像の保存（キャッシュ）を読み、再利用できる素材と作り直す範囲を区別します。
ニュース動画の品質検査を差し戻しへつなぐ——出典・表示・数値照合で再制作を分岐
出典不足は制作前へ、表示警告は許された修正へ、数値不一致は材料の照合へ戻します。ニュース制作で使う分岐を基に、修正後の再書き出しと再QA、通常三回、上限六回で止める条件と、処理の終了コード（成否を示す番号）だけでは分からない受入結果を解説します。
5秒の生成素材を36秒の解説へ——Pythonで静止・速度調整・逆再生を組む
約5秒の人物映像を、9場面の無音解説へ編集した試作です。Pythonで素材時刻を選び、静止、速度調整、逆再生と説明カードを構成しました。素材と完成物を区別し、映像全体を通して確認する検査と、別担当による画面確認の範囲を示します。
商品写真から15秒CMを組む——ローカル動画生成・採用区間・FFmpeg（動画処理ツール）検査
架空商品のデモで、手元の環境で生成した3つの素材から各5秒を通常の速さで採用し、文言は編集作業で配置しました。入力の切り出し、音声と字幕の版管理、動画処理ツールのFFmpegで、全コマを読み切る検査、保存素材からの編集再現を追い、生成成功と広告素材の受入を分けます。
画像の会社紹介をGoogleスライドへ再構成する——編集できる要素・本文の照合・見た目の差の検証
十二ページの自社の会社紹介資料で、本文をテキスト、主要図を図形と接続線へ移し、空欄と承認済み文言を保持しました。この制作を例に、一枚画像の貼り付けとの違い、変換先での文字読み戻し、改行と図の意味を確認する手順を解説します。
SQLiteで自動清掃の日次予算を管理する——日本時間の予約上限と読み取り継続
自動清掃の上限「一日三件」は、成功した件数でも、担当（AI）を起動した回数でもなく、実行を予約した件数で数えます。SQLiteの予約台帳から、日本時間の日付境界、結果不明でも戻さない枠、重複予約の拒否、上限後も診断を続ける分岐を読み解きます。
障害監視の成功を分解する——工程の実行記録と観測期間で復帰を判定する
診断報告の完成、ログ取得の復帰、利用者の画面回復は別の結果です。工程の実行記録を使い、時計の調整に左右されない経過時間、中断の検出時刻、同一工程の後続成功、エラー取得の期間と件数から、復旧報告で言える範囲を整理します。
SQLiteへ送信前予約を残す——タイムアウト後も同じ操作を二度送らない設計
外部操作の返事だけが失われたとき、再送すれば二重実行になり得ます。保守作業で使うSQLiteの一括処理（トランザクション）と作業単位の予約を読み、送信前保存、結果不明の保持、相手側への照会を分ける設計を解説します。
AI記事の公開前ゲートを設計する——出所の確認と承認内容の照合で書き出しを止める
三本の記事の一本だけに根拠がないとき、何を止め、何を人へ渡すか。記事制作基盤にある来歴検査、レビュー待ち、複数の記事と公開先への承認の照合を解説します。この記事で扱うのは手元への書き出しまでで、本番サイトへの自動投稿は含みません。
AI成果物の受入を三段階に分ける——JSON形式の検査・SHA-256照合・別担当レビュー
AIの完成宣言を納品の根拠にしないために、提出物の組とJSONの型を機械検査し、業務上の意味を別担当が読み、最後にSHA-256（ファイルの内容から作る識別値）で確認した版を照合します。備品集計の場面を通じて、作業の受入条件と検査の限界を示します。
LangGraph＋SQLiteでAIジョブを再開する——状態保存と再実行の設計
AI作業が止まったとき、依頼を再発行するのか、提出やレビューを待つのか。LangGraphとSQLiteによるジョブ基盤を例に、状態保存、試行の識別、排他（同時に動かさない仕組み）、最終再検証で再開先を決める設計を解説します。
該当する項目がありません。キーワードやテーマを変えてください。
LET’S BUILD
AIを、自社の業務へ。
対象業務と、任せたい仕事を教えてください。試作から既存システムへの接続まで、必要な開発範囲を一緒に整理します。
開発について相談する →オンライン相談を予約する（無料）↗