Articles

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導入で特に起きやすいアンチパターンと、その回避策を整理します。

多くのプロジェクトにおいて、問題は「ソフトウェアが存在しないこと」ではありません。 本当の問題は、複数のシステムが連携せず、業務として機能していないことです。 あるシステムでは正しいデータが、別のシステムでは異なっている。 データが重複し、遅延し、時には失われる。 結果として、現場では Excel やメール、手作業に戻ってしまいます。 ここに、私たちの本質的な強みがあります。

日本のセキュリティチームは、どのようにAIを活用してWazuh運用を高度化しているのか 日本企業におけるWazuh運用が難しい理由 Wazuhは、オープンソースでありながらSIEM/XDRとして高い柔軟性と拡張性を持つプラットフォームです。コストを抑えつつ自社でコントロールしたい日本企業にとって、有力な選択肢となっています。 一方で、その柔軟性は運用負荷の増大にも直結します。日本のSOCや情報システム部門では、次のような課題が頻繁に発生します。 検知ルールを業務実態に合わせて正確に設計する難しさ 誤検知（False Positive）を抑えつつ検知力を維持するバランス 技術的な検知結果を経営層・監査部門に説明する必要性 ISO 27001、NIST、社内統制への対応 エージェント数・ログ量増加に伴う性能と運用の問題 AIはセキュリティ専門家の代替ではありません。 しかし、正しく使えば、熟練エンジニアの思考プロセスを再現・加速させることができます。 そのための実践的な手段が Wazuh Admin Prompt Packs です。

日本の中央省庁や地方自治体には、数十年前に構築された基幹システムが今なお社会インフラとして稼働しているケースが少なくありません。これらのシステムは、現代的なデジタル体験には適合していないものの、日々の行政サービスを確実に支え続けています。 しかし課題が顕在化すると、しばしば次のような発想に行き着きます。 「古いシステムをすべて新しく作り直そう」 一見合理的に見えるこの判断が、日本の政府ITプロジェクトでは高い確率で失敗します。その理由を理解することが、より良い解決策への第一歩です。

日本の自治体（市区町村・都道府県）は、共通した課題に直面しています。 人口減少・高齢化による職員不足 行政サービスの高度化と業務量の増加 長年運用されてきた基幹系・業務系システム（レガシーシステム） AIは注目されていますが、自治体におけるAI導入の多くは PoC（実証実験）止まり で終わっているのが現実です。その主な理由は、AIを「技術起点」で導入し、実際の行政業務フローに組み込めていないことにあります。 そこで重要になるのが Vertical AI（業務特化型AI） です。 Vertical AIは、チャットボットや汎用モデルから始めません。代わりに、以下を起点とします。 実際の行政業務 法令・条例・ガイドライン 既存システムとの関係 説明責任・監査対応 その上で、AIを業務プロセスの中に安全に組み込むことを目指します。 本記事では、日本の自治体が現実的に導入でき、効果を出しやすいVertical AIのユースケースを整理します。

日本の行政におけるデジタル化は、単なるWebサイトや申請システムの刷新ではありません。実際の課題は、省庁・都道府県・市町村・外郭団体といった複数組織が関与する中で、いかに一貫したサービスを提供できるかにあります。 本記事では、日本の行政文化・制度・既存システム（レガシー）を前提とし、実務で機能するデジタルサービスデリバリーの設計原則を解説します。技術トレンドよりも、持続可能性と現実性を重視します。

日本におけるデジタル行政サービスは、「業務効率化」「住民利便性の向上」「人手不足への対応」といった大きな期待を背負って導入されます。しかし現実には、本番稼働後に定着せず、形骸化したり、現場で使われなくなるケースが少なくありません。 本記事では、日本の中央省庁・自治体プロジェクトで実際に見られる事例をもとに、デジタル行政サービスが本番稼働後に失敗する7つの主な理由を整理します。

日本の都道府県・市町村は、デジタル化において独自の課題を抱えています。システムは10〜20年にわたって安定稼働することが求められ、国のプラットフォームとの連携、複雑な調達制度、頻繁なベンダー変更にも耐えなければなりません。 本記事では、特定の製品やベンダーに依存しない、実務に即したリファレンスアーキテクチャを紹介します。焦点は、最新技術ではなく、構造・連携・持続性です。

日本の地方自治体（都道府県・市区町村）は、限られた予算、人材不足、そして長年運用されてきたレガシーシステムを抱えながら、住民サービスのデジタル化を求められています。加えて、縦割り行政、ベンダー依存、制度改正への対応といった構造的課題が、GovTechの推進をさらに難しくしています。 多くのGovTechプロジェクトが期待通りの成果を出せない理由は、技術選定そのものではなく、システム全体の設計が部門単位で分断されていることにあります。 本記事では、日本の地方自治体が現実的に導入・運用できる 「統合（Integration）を中心に据えたGovTechアーキテクチャ」 を紹介します。既存システムを活かしながら、段階的に近代化できる構成です。

大規模災害が発生したとき、最初に機能しなくなるのは人ではなく、インフラであることが少なくありません。地震、津波、台風、豪雨、土砂災害、原子力・産業事故――その瞬間、停電が起こり、通信回線は輻輳し、インターネット接続は不安定、あるいは完全に失われます。 それにもかかわらず、多くの「スマート」な緊急対応システムは、常にネットワークが利用可能であるという前提で設計されています。 この前提は、現実の災害対応においては成立しません。 緊急対応システムは、付加的な機能としてではなく、根本設計として Offline First である必要があります。

はじめに：失敗の原因は技術そのものではない 日本の地方自治体におけるデジタル化プロジェクトは、厳格な調達制度、縦割りの組織構造、担当者の異動、そして長年利用されてきた既存システムへの依存といった、固有の環境の中で進められています。 多くのケースで、プロジェクトが期待した成果を出せない理由は、技術が高度すぎるからではありません。実際の行政業務や運用の現実を前提に、システムが設計されていないことが最大の要因です。 予算は執行され、システムは納品されますが、結果として次のような状況が残ります。 職員は結局 Excel や紙の管理に戻る 住民は窓口での手続きを続けなければならない 部署ごとにデータが分断され、重複が発生する システム間の連携が実質的に機能していない 見落とされがちな事実は次の点です。 多くの自治体システムは、コードを書く前の段階ですでに失敗が決まっているということです。

なぜ今、この話をするのか 大きなテクノロジーには、いつも似た感情の流れがあります。 期待 → 過剰な約束 → 失望 → 静かな価値創出 AIも例外ではありません。 違いがあるとすれば、そのスピードです。AIブームは非常に速く広がり、今まさに多くの日本企業が次の事実に気づき始めています。 「AIが賢いだけでは、ビジネス価値は生まれない」 本記事では過去の技術ブームを振り返りながら、 ブームが去った後に何が残り、何が本当の価値になるのかを整理します。