Articles

はじめに 現代の Security Operations Center（SOC）において、「迅速な対応」と「一貫性のある判断」は非常に重要です。アナリストによる手動トリアージは時間がかかり、判断のばらつきも発生します。 そこで必要になるのが Automated Decision Logic（自動意思決定ロジック） です。構造化されたルールやスコアリングモデルに基づき、セキュリティアラートを自動評価し、次のアクションを決定します。 本記事では、以下の構成を前提に解説します： Shuffle（SOAR 自動化プラットフォーム） Wazuh（SIEM） DFIR-IRIS（インシデント対応管理） PagerDuty（オンコール通知） 自社開発 SOC Integrator（Django ベース） 実践的な例と、実運用可能なアーキテクチャを紹介します。

現代のSOC（Security Operations Center）は非常に強力なツール群で構成されています。 例えば以下のような構成が可能です。 Wazuh（検知・相関分析） Shuffle（SOAR自動化） IRIS（インシデント管理） PagerDuty（エスカレーション／オンコール対応） しかし、多くの組織が運用開始から数か月後に直面する問題があります。 ツール同士を直接接続する構成は、時間とともに複雑化し、制御不能になりやすい という点です。 そこで私たちは、単純なツール間連携ではなく、以下のアーキテクチャを採用しました。 SOC Integrator — APIオーケストレーション層

近年のEV充電プラットフォームは、単に充電するだけでなく、遠隔制御・リアルタイム監視・外部システム連携が求められています。 本記事では、実際に稼働しているOCPP 1.6デモ環境を用いて、Webダッシュボード、Backend API、OCPP WebSocket通信までを一貫して紹介します。 目的は明確です。スライドではなく、実運用レベルで動作するCSMSを体験してもらうことです。

現代のソフトウェア開発は、もはや「どれだけ速くコードを書けるか」や「どれだけ多くのフレームワークを知っているか」で評価される時代ではありません。2026年において最も価値の高いエンジニアとは、システム全体を考え、リスクを見抜き、ソフトウェアを実際のビジネス成果につなげられる人材です。 AIによるコード生成の普及は、この変化を一気に加速させました。 本記事では、ソフトウェア開発者のスキルがどのように進化しているのか、なぜ従来の「シニアエンジニア」という定義が通用しなくなっているのか、そしてこれから本当に重要になるスキルは何かを解説します。

Retro Tech Revivalは、もはや懐古趣味やコレクターの世界の話ではありません。現在では 実践的なプロダクト開発戦略 として再評価されており、特に offline-first・高信頼・長期運用を重視するチームにとって重要な考え方になっています。 サブスクリプション、クラウドロックイン、終わりのない通知に囲まれた現代において、多くのユーザーは次のように感じ始めています。 本当に信頼できて、長く使えるツールが欲しい 本記事では、Retro Tech Revival → 実際に作れるプロダクトアイデア を、ソフトウェアとハードウェアの両面から整理します。

通信が途切れても、現場の仕事は止まらない 現場業務は理想的な環境で行われるとは限りません。点検、保守作業、現地調査、災害対応などは、通信環境が不安定、または完全に圏外の場所で行われることが多くあります。 クラウド前提のツールは、まさにそのような重要な場面で使えなくなることがあります。 OffGridOps は、そうした現実の現場のために設計されました。 OffGridOpsは、オフラインファースト設計のフィールドオペレーションアプリです。サーバーや常時インターネット接続に依存せず、サイト、作業、タスク、インシデントを、証拠付きで確実に記録できます。

農業は、常に安定したインターネット環境がある場所で行われるとは限りません。 多くの農家は、ノートへの手書きメモや散在する写真、記憶に頼って圃場や作業、収穫の管理を行っています。 SmartFarm Lite は、そうした現場の現実から生まれました。 SmartFarm Liteは、オフラインファースト設計の農業記録アプリです。 インターネットやクラウドに依存せず、農作業に必要な情報をすべて手元のスマートフォンに記録できます。

市場価格を正確に予測することは非常に困難です。本記事では「AIが価格を当てる」と主張するのではなく、より現実的で実務的なアプローチを採用します。 説明可能なヒューリスティクスを用いて、短期的に価格が上昇・下落する可能性を評価する 本記事では、スクリプトの設計思想、使用しているシグナル、そして実務での活用方法を解説します。AI hype やブラックボックスを意図的に避けています。

言語設計の思想 Python：開発スピードと柔軟性を最優先 Pythonは「人間の生産性」を最大化するための言語です。 シンプルで読みやすい構文 圧倒的なライブラリエコシステム 試行錯誤に強い 向いている用途： MVP・PoC開発 要件が頻繁に変わる業務システム AI・データ分析・自動化

チャンタブリー県は、ドリアン、マンゴスチン、ランブータンなどで知られる、タイ有数の果物生産地です。しかし高品質な農産物を生産しているにもかかわらず、多くの農家は価格変動の大きさや外部市場への過度な依存に苦しんでいます。 この問題の本質は国際貿易そのものではなく、情報・供給調整・市場アクセスを誰が握っているかにあります。ここにこそ、ソフトウェア技術が大きな役割を果たします。

金融のチャンスは、明確な形で現れることはほとんどありません。多くの場合、価格・リスク・市場の期待が一時的にズレた瞬間に生まれます。 AI（人工知能）は未来を正確に予測する魔法の道具ではありません。しかし、「成功確率が高い状態」を人間よりも早く、体系的に検知する能力に優れています。 本記事では、短期取引から中長期のマクロ投資まで、AIがどのように金融機会を発見するのかを、技術とシステムの視点から解説します。

ONNX（Open Neural Network Exchange）は、機械学習モデルを 一度学習し、複数の環境で再利用 できるフォーマットです。PyTorch や TensorFlow で学習したモデルを、Android / iOS / React Native / Flutter などのモバイル環境へ効率的に展開できます。 本記事では、React Native での ONNX 利用 を中心に、オンデバイス AI や Local LLM をモバイルアプリに組み込むための考え方と実践ポイントを解説します。

はじめに 日本でも近年、葉の画像からAIが病害を検出する技術 が、実証事業やスマート農業プロジェクトを通じて広く知られるようになりました。一方で、「写真1枚で正確に病気を診断できる」という期待が先行しているケースも少なくありません。 実際の現場で使われているシステムは、完璧な診断を目的としたものではありません。日本の農業環境に適応するため、現実的で信頼できる判断支援 に重点を置いて設計されています。 葉の病害検出アルゴリズムは、農業指導員や専門家を置き換えるものではなく、初期段階の不確実性を減らすための補助ツール です。葉の画像情報に加え、気象条件や直近の作業履歴といった文脈情報を組み合わせて活用します。 本記事では、日本の農業現場に適した視点から、葉の病害検出アルゴリズムが実際にどのように機能しているのか を、Smart Farming Lite の考え方を例に解説します。

はじめに 日本の農業は、小規模・中規模農家の多さ、高齢化、家族経営という構造的な課題を抱えています。スマート農業は国策として推進されていますが、実際の現場ではコスト、運用の複雑さ、保守負担の高さから、十分に定着していないケースも少なくありません。 Smart Farming Lite は、この日本の現実に合わせて設計された、スマートフォン中心・意思決定支援型のデジタル農業システムです。専用センサーの導入を前提とせず、農家がすでに持っている道具と日常作業に自然に溶け込むことを重視しています。 完璧なデータ収集を目指すのではなく、「今日、何をすべきか」を明確にすることがSmart Farming Liteの目的です。

― 既製MESが現場で機能しなくなる理由 ― 日本の多くの工場で、MES導入が期待通りの成果を出せない原因は、技術力の不足ではありません。 問題は、システムが日本の現場の実態に合っていないことです。 パンフレット上の既製MESは完璧に見えます。 経営向けのOEEダッシュボード 監査・ISO対応のトレーサビリティ 本社向けの生産レポート 品質・法規制チェックリスト しかし、日本の製造現場では次のような状況が珍しくありません。 MESと並行してExcelが使われ続ける 現場責任者が数値を手作業で補正する 生産を止めないためにシステムが迂回される 会議では改善よりも「数字の正しさ」が議論される これは現場の問題ではありません。 設計思想の問題です。

誰も避けられない静かな変化 過去20年以上にわたり、インターネットは明確なルールで機能してきた。知りたいことがあれば検索し、リンクをクリックし、Webサイトを読む。書き手はトラフィックや評価、時には収益を得てきた。 しかし、ChatGPTのようなAIは、この循環を静かに壊し始めている。 今日、人々はまず「検索」するのではなく、「質問」する。そして答えは即座に提示され、元のWebサイトを訪れる必要はなくなった。 ここで生じる根本的な問いがある。 AIがすべて答えるなら、誰がコンテンツを書くのか。

はじめに 日本のリサイクル事業（スクラップ業）では、次のような悩みをよく耳にします。 「今、銅スクラップや鉄スクラップを積極的に買っていいのか？」 重要なのは、価格を完璧に当てることではありません。 毎日の意思決定を、少しずつでも合理的にすること が最大の目的です。 本記事では、日本市場の実情に合わせて、投機やトレードをしない価格予測の考え方 を解説します。

AI時代のソフトウェアエンジニアのための生存ガイド 『Who Moved My Cheese?』は、一見するととてもシンプルな物語です。 しかしそのメッセージは、AI時代を生きるソフトウェアエンジニアにとって非常に現実的です。 AIは単にツールを進化させただけではありません。 チーズ（価値の源泉）を動かしました。

なぜ日本でShopeeやAmazonと競争するべきではないのか 日本でEコマースシステムを検討する際、多くの企業が最初に抱く疑問は次のようなものです。 「Amazonや大手ECがすでにある中で、自社でシステムを作る意味はあるのか？」 結論から言えば、競争すること自体が目的ではありません。 Amazonや大手ECプラットフォームは、低摩擦・大量取引・標準化された購買体験に最適化されています。一方、日本の多くの企業活動は、契約・承認・文書・責任所在を重視する構造で成り立っています。 この構造的な違いこそが、日本向けに最適化されたEコマースシステムが価値を持つ理由です。

近年、日本でも官公庁（GovTech）、自治体、金融機関、製造業を中心にAI導入が急速に進んでいます。 「人手不足の解消」「業務効率化」「判断の自動化」といった期待のもとでAIプロジェクトが立ち上がりますが、実運用フェーズでシステムが破綻するケースも少なくありません。 その原因は、AIモデルの性能不足ではなく、AIを従来のシステム設計思想と混同して使ってしまうことにあります。 本記事では、日本の組織文化・監査要件・リスク感度を踏まえ、AI導入で特に起きやすいアンチパターンと、その回避策を整理します。