Articles

プロジェクトのキックオフでは、ほぼ必ずと言っていいほど「あの大きなフレームワークを使おう」という提案が出る瞬間があります。専用のカンファレンスがあり、認定資格コースがあり、「エンタープライズ」プランがあり、「これ一つで何でもできる」と謳うスライドがある、あのフレームワークです。そして多くの場合、それを選ぶことこそが、プロジェクトにおける最初の静かな過ちとなります。

あなたのSOCで最も優秀なTier 1アナリストが、ついに退職願を出しました。 彼女は1年半そこにいました。労働時間が理由ではありません。給与が理由でもありません。彼女が辞めた理由は、この1年半、同じ五種類のフォールスポジティブのアラートを、互いに会話しない五つのツールの中で、誰も2022年以来更新していない三段落のプレイブックPDFに従ってトリアージし続けたからです。仕事が意味を失ったから辞めたのです。

ERP統合の救済プロジェクトのキックオフで、必ず耳にする台詞があります。 「UATでは完璧に動いていたんですが…」

どの企業の情報システム部門にも、「プロジェクトの墓場」が存在します。 そこには、2024年に経営会議を沸かせたデモ、選び抜かれた3つの質問でChatGPTを上回ったRAGプロトタイプ、サンドボックス環境で無敵に見えたAIコパイロットが眠っています。そして、誰かが本当に難しい質問を投げかけます — 4,000人の従業員の前に出せるのか? ERPと連携できるのか? 顧客データに対して、監査と個人情報保護法の要件を満たした上で運用できるのか? — その瞬間、プロジェクトは静かに「フェーズ2」へと送られます。

ERPNext を国内の製造業 (精密部品、熱処理、食品加工、リサイクル、受託製造など) で運用している、または海外子会社の ERP として導入している場合、選定理由は妥当だったはずです。Manufacturing モジュールは BOM、製造指図、外注、ロット管理を実用的なレベルで処理します。Frappe フレームワークは本当に拡張性があります。Enterprise ライセンスのアップチャージがないため、SME 規模で運用してもコスト構造が成立します。

東京や大阪の経理部が月 200 件のベンダー請求書を Odoo に手入力していて、1 件あたり 4 分かかっているとしましょう。それだけで月 13 時間の純粋なデータ入力時間です。月次決算で発覚する仕訳ミスの修正、源泉徴収の計算、海外仕入先からの英語・中国語請求書の処理、輸入通関書類との突合まで含めると、本来自動化されているべき業務に正社員 1 人分のリソースを使っていることになります。

「ERP連携はすでに解決済みの課題だ」——SIベンダーはそう言います。しかし、製造業の現場——特に自動車・電機メーカーの二次・三次サプライヤー——では現実はまったく異なります。脆弱なポイント・ツー・ポイント連携、属人的なカスタマイズコード、そしてベンダーがスキーマを更新するたびに停止するレガシーミドルウェア。データは存在します。システムも存在します。その間の断絶こそが、業務効率を失わせている原因です。

ほとんどのエンジニアリングブログは、すでに読み手として存在している人を対象に書かれています。本サイトは、これから問題に 直面しようとしている エンジニア、創業者、または運用責任者 — そして、ベンダーのホワイトペーパーを要約しただけではなく、実際に動作するシステムを世に出した人を探している人 — を対象に書いています。

誰も話したがらないデータソース 日本、タイ、中国の工場の総務部に行って、先月の電力消費データはどこにあるか聞いてください。返ってくる答えはシステムへの誘導ではありません。フォルダへの誘導 — 物理的、または電子的 — の中に、地元電力会社からの PDF が積まれています。コンピュータ生成のものもあります。総務担当者が手書きの工場コードを足した紙のバルの紙のスキャンもあります。判子が押されているものもあります。2 ページ折りで 2 ページ目が真っ直ぐスキャンされていないものもあります。

日本の総合商社、メーカー、化学・食品セクターの大手企業の CFO が、Big 4 の CSRD 対応提案書を初めて見たときの反応は、ほぼ例外なくある種の戸惑いです。初年度 €2–4M(約 3.5–7 億円)。継続運用 €400–900K(約 7,000 万–1.6 億円)。時間単価に換算すると、シニアパートナーで 6 万–10 万円/時間。提案書には Gantt チャート、ステークホルダーマップ、「ESRS readiness assessment」と銘打たれた方法論スライド、そして全コストの約半分を吸収する「データ統合およびシステム関連業務」という曖昧な行が含まれています。

5 億円の見積書と、説明されない一行 ここ最近、繰り返し目にするパターンがあります。日本の総合商社やメーカーの本社サステナビリティ部門に、欧州子会社が CSRD(Corporate Sustainability Reporting Directive、企業サステナビリティ報告指令)の対象に該当することを示す内部メモが届く。純売上高が €50M を超え、従業員 250 名以上、上場または十分な規模の事業体で、2025 年 12 月に採択された Omnibus 簡素化パッケージでも対象から外れなかった事業体です。最初のサステナビリティ報告書の提出期限が見えてきて、監査法人との打ち合わせが始まり、「CSRD 対応ソフトウェア」の調達プロセスが動き出します。

この 18 か月間、セキュリティ製品を持つベンダーは皆、マーケティングページに「AI」というラベルを貼り付けてきました。その大半は再ブランド化された ML 分類 — もともと存在していた異常検知に 2024 年の衣装を着せたもの — に過ぎません。本当に興味深い、そしてほとんどのチームが失敗するのは、tool-using LLM agent をアラートパイプラインに実際に組み込み、Tier-1 アナリストのようにトリアージさせようとした時です。

日本のサイバーセキュリティ市場で、これまでにない規模の需要波が形成されつつあります。しかし、それを支えるべきインフラベンダー側は、構造的にこれを吸収する準備ができていません。

RAM、VRAM、GPUは実際にどれだけ必要なのか — 過剰投資せず、想定外のトラブルにも遭わずにローカルLLMを動かすための、エンジニア向けの実用ガイドです。

中堅企業向けに、Wazuh、DFIR-IRIS、Pythonで自作したミドルウェアで本番運用のSOCを構築した実装記録です。実際に効いた設計、つまずいた箇所、そして本当に重要だった技術判断を整理します。

なぜ農業IoTにDSLが必要だったのか 農業IoTの自動化システムを構築するとき、エンジニアはたいてい次のどちらかを選ぶ。 YAML/JSONベースの設定ファイル — シンプルだが、条件分岐が複雑になると破綻する 汎用言語（Python/Node.js）で直接実装 — 柔軟だが、農業の専門家がロジックを読めない

スマート農業技術はかつてないほど手の届きやすいものになった。土壌センサーのコストは数年前と比較にならないほど下がり、LoRaWANゲートウェイは1回の充電で数キロメートルをカバーし、クラウドプラットフォームは数千のデバイスからのテレメトリをほぼゼロの追加コストで処理できる。AIモデルはスマートフォンの写真から作物の病害を診断する。

毎年、タイ・日本・東南アジア全域の企業が、業務効率化・リアルタイムの可視化・長期的なコスト削減を期待してERPシステムに多額の投資を行っている。しかし、実態は期待とかけ離れたケースが少なくない。

はじめに ドローンはもはや単独の存在ではありません。捜索救助、精密農業、インフラ点検、安全保障といった現代のミッションは、スウォーム（群れ）への依存度を高めています。スウォームとは、タスクを分担し、状況認識を共有し、単機では達成できない目標を協調して実現するUAV群です。

NumPyを使い始めてしばらくすると、こんな経験をすることがある： a = np.array([1, 2, 3]) b = np.array([10, 20, 30]) result = a + b # [11, 22, 33] ✅ 直感的に理解できる