「コードを書く」から「ループを回す」へ——AIエージェント・ハーネスとMCPが描く、日本のSIer・製造業が直面する次の壁
 2026年7月、人工知能をめぐる「実装の地層」がまた一つ厚くなりました。 
2026年7月、人工知能をめぐる「実装の地層」がまた一つ厚くなりました。
先週だけで、以下の三つの動きがほぼ同時に報じられました。
- ITmedia AI＋（7月3日）：アルミン・ロナッハー氏（Flask/Sentry作者）の記事をベースに、「AIコーディングにおける『ループ』には、エージェントが回す 内側ループ と、ハーネスが回す 外側ループ の二種類がある」と整理。外側ループがもたらす「記憶・評価・修正」の自動化こそが、次の生産性飛躍の鍵だと論じました。
- ITmedia AI＋（7月2日）：川崎重工業・ファナック・安川電機の国内ロボット大手三社が 「フィジカルAI」向けデータセットを共同構築 すると発表（GENIAC採択）。同週、中国AGIBOTがタブレット量産ラインで人型ロボットを 64時間・17,625台・成功率99.99％ で稼働させたライブ配信を実施しました。
- Hacker News（7月3日）：MCP（Model Context Protocol）専用クラウド Manufact がローンチ。「MCPは新しいウェブサイト、AIチャットは新しいブラウザ」というパラダイムのもと、MCPサーバの開発・テスト・ストア公開・監視を一体化する垂直統合基盤が登場しました。
これらは一見無関係に見えますが、共通するのは 「モデル単体の賢さ」から「ハーネス・プロトコル・データの三位一体でエージェントを動かす基盤」へのシフト です。本稿では、この構造変化を ①開発現場のループ構造 ②MCPという新しいプロトコル層 ③フィジカルAIと日本の製造業 の三軸で読み解き、日本のSIer・ユーザー企業がいま押さえるべき論点を整理いたします。
1. 「コード生成」から「ループ運用」へ──内側・外側ループの二層構造
1-1 アルミン・ロナッハーが示した二つのループ
ITmedia AI＋が紹介したアルミン・ロナッハー氏の記事「Software engineering becomes writing loops」は、AIコーディングの現在地を言い当てています。
| ループ | 主体 | 役割 | 典型的ツール・概念 |
|---|---|---|---|
| 内側ループ | エージェント（LLM） | コード編集・テスト実行・エラー修正を 自律的に反復 | Claude Code、Cursor、GitHub Copilot Agent、Codex CLI |
| 外側ループ | ハーネス（制御基盤） | タスク分解・計画・評価・記憶管理・人間へのエスカレーションを 俯瞰的に制御 | 独自オーケストレータ、LangGraph、AutoGen、MagenticLite、Manufact等 |
ポイント：内側ループは「コードを書く」作業そのものを高速化しますが、外側ループは 「何を書くべきか、どう評価し、どう記憶し、いつ人間に戻すか」 を決めるメタ層です。ロナッハー氏は「外側ループの設計こそが、今後のエンジニアリング生産性を分ける」と断じています。
前回の Smart Kurashi では 「AIエージェント『制度化』の三重奏——カリフォルニア州×Anthropic、freee10分構築、GitHubがPR制限で示すガバナンスの行方」 で、AIエージェントが「概念」から「制度」へ移行する過程を整理しました。今回は、その「制度化」の裏側で動く 「ハーネス（外側ループ）」 という実装基盤のレイヤーに焦点を当てます。
1-2 日本のSIer現場では何が起きているか
この二層構造は、日本のSIer・ユーザー企業にとって 「生成AI導入プロジェクト」の失敗要因を言語化 するものでもあります。
多くの企業が2023〜2024年にかけて取り組んだのは、内側ループ相当の「コード生成支援（Copilot導入、プロンプトエンジニアリング研修）」でした。しかし、外側ループ（タスク分解・品質ゲート・知識蓄積・人間判断への引き継ぎ）を整備しないまま内側ループだけ高速化しても、レビュー負荷が増えて全体リードタイムが伸びる という「ジェボンズのパラドックス」に陥っています。
ThinkIT（7月2日）の記事「【利用率から運用設計へ】生成AIをめぐる『競争軸』と『課題』の変遷」でも、2024年は「利用率・プロンプト技術」が競争軸だったのに対し、2025年以降は 「運用設計・評価基盤・ガバナンス」 へシフトしていると整理されています。まさに 内側ループ競争から外側ループ競争への移行 です。
1-3 ハーネス実装の三段階
外側ループ（ハーネス）を自社で構築・運用する成熟度は、おおむね三段階に分けられます。
| 段階 | 状態 | 課題 | 日本企業の典型例 |
|---|---|---|---|
| Level 0 | エージェントを「道具」として個別利用 | 再現性なし、知識共有なし、セキュリティ監査不能 | 多くのユーザー企業（Copilot導入止まり） |
| Level 1 | 共通プロンプト・テンプレート・評価スクリプトを整備 | タスク分解・記憶管理が手動、スケールしない | 先進的なSIer一部、社内AI推進室 |
| Level 2 | ハーネス基盤を内製・運用（オーケストレータ・メモリ・評価・MCP統合） | 高度なエンジニアリング投資が必要、継続的改修コスト大 | 極少数（楽天、NTTデータ、日立製作所等） |
Level 2に到達している国内事例として、楽天グループの「AIエージェントによる運用コスト・遅延30％低減」（ITmedia AI＋ 6月30日）、日立製作所の「Hitachi iQ Studio」によるミッションクリティカル領域支援（ITmedia Enterprise 7月2日）、NTTデータ×Google Cloudのエージェント型基盤構築などが挙げられます。これらに共通するのは、「モデル選定」より「ハーネス設計・運用」にリソースを割いている 点です。
2. MCP——「新しいウェブサイト、AIチャットは新しいブラウザ」の衝撃
2-1 MCPとは何か、なぜ今なのか
Model Context Protocol（MCP）は、Anthropicが2024年11月に発表した 「LLMと外部ツール・データソースを標準化して繋ぐプロトコル」 です。HTTP/RESTが「ウェブサーバとブラウザ」を標準化したように、MCPは 「MCPサーバ（ツール・データ提供側）」と「MCPクライアント＝AIチャット・エージェント」 を標準化します。
2025年前半は「仕様策定・SDK整備」のフェーズでしたが、2025年後半から2026年にかけて 実装・エコシステム形成 が加速しました。
- MCPサーバ登録数：2026年7月時点で 1,200件超（公式レジストリ＋非公式含む）
- 主要クライアント対応：Claude Desktop、Cursor、Windsurf、Cline、VS Code拡張、Continue.dev等
- エンタープライズ採用：Stripe、GitHub、Linear、Notion、Atlassian等が公式MCPサーバを公開
2-2 Manufact——MCP専用クラウドの登場が意味するもの
Hacker Newsで報じられた Manufact（manufact.dev） は、MCPサーバの 開発・テスト・ストア公開・監視・課金 を一体化した初の垂直統合クラウドです。
| 機能 | 従来（自前構築） | Manufact |
|---|---|---|
| MCPサーバ開発 | ローカルでPython/TypeScript書く、デバッグ辛い | Web IDE＋即時プレビュー＋自動テスト |
| 公開・配布 | GitHub Pages等で自前ホスティング | ワンクリックでストア掲載、バージョン管理 |
| 監視・ログ | 自前でDatadog等連携 | 組み込みダッシュボード（呼出・遅延・エラー率） |
| 課金・収益化 | Stripe連携を自前実装 | 組み込み課金（従量・サブスク・無料枠） |
「MCPは新しいウェブサイト、AIチャットは新しいブラウザ」 このパラダイムが正しければ、Manufactは 「新しいNetlify/Vercel」 に相当します。ウェブ黎明期に「サーバを自分で立てる」から「PaaSにデプロイ」へ移行したのと同じ構造変化が、いまエージェント基盤層で起きようとしています。
2-3 日本企業にとってのMCP戦略的選択肢
日本企業には三つの選択肢があります。
| 選択肢 | メリット | デメリット | 向く企業 |
|---|---|---|---|
| A. 公開MCPサーバを「消費」するのみ | 導入即効性高、運用コスト低 | 差別化困難、ベンダーロックイン、データ主権リスク | PoC段階、リソース不足の中堅・中小 |
| B. 自社専用MCPサーバを「内製・自社ホスト」 | データ主権確保、業務固有ロジック実装可、内部統制容易 | 開発・運用リソース大、セキュリティ責任自社 | 機密データ扱う大手・金融・製造・官公庁 |
| C. Manufact等PaaSで「内製・マネージド運用」 | インフラ運用軽減、標準監視・課金機能、市場展開も可 | プラットフォーム依存、コスト増、日本リージョン未対応の可能性 | ステストア展開狙うスタートアップ・先進SIer |
推奨：機密性の高い業務（基幹システム連携、設計図面・製造データアクセス等）は B、汎用業務（ドキュメント検索、チケット起票、カレンダー操作等）は A または C と使い分ける 「ハイブリッドMCP戦略」 が現実的です。特に オンプレミス・プライベートクラウド前提の日本大手企業では、MCPサーバ自体をオンプレミス配置できるアーキテクチャ（B）が必須 になります。
3. フィジカルAI——「データセット共同構築」から「量産実証」へ、日本製造業の分岐点
3-1 国内ロボット三社のデータセット共同構築（GENIAC採択）
ITmedia AI＋（7月2日）によれば、川崎重工業・ファナック・安川電機が 「フィジカルAI」向けデータセットを共同構築 することで合意し、経産省GENIAC（次世代AI基盤整備事業）に採択されました。
フィジカルAI とは、「デジタル空間で学習したモデルを物理ロボットに転移し、現実世界での認識・判断・行動を可能にするAI」を指します。従来の「教示再生（ティーチング・プレイバック）」から、「模倣学習＋強化学習＋シミュレーション大量試行」 へ移行するための 「ロボット版ImageNet」 が必要とされています。
三社が共同構築するデータセットの想定規模・内容：
| 項目 | 内容 |
|---|---|
| 対象タスク | ピッキング、組立、検査、搬送、溶接等の汎用マニピュレーション |
| データ形式 | 多視点カメラ映像＋関節角度＋力覚＋タスク成功/失敗ラベル＋シミュレーション合成データ |
| 規模目標 | 実ロボット10万エピソード相当＋シミュレーション1000万エピソード相当 |
| 公開方針 | 学術研究用途は一部公開、商用利用はライセンス制（三社共同管理） |
意義：国内ロボットシェア上位三社（世界シェア約50％）が 競争領域（ロボット本体・コントローラ）と非競争領域（学習データ基盤）を切り分け、後者で協調 する初の本格事例です。これは 「データを持つ者がフィジカルAIを制する」 という認識の表れです。
3-2 AGIBOTの衝撃——64時間・17,625台・成功率99.99％
同週、中国の人型ロボット開発企業 AGIBOT（智元機器人） が、実際のタブレット量産ラインで複数の人型ロボットを 64時間連続稼働 させ、17,625台の生産に貢献、作業成功率99.99％ を達成したライブ配信を実施しました（ITmedia AI＋ 7月2日）。
| 指標 | AGIBOT実証 | 従来のロボット導入基準 |
|---|---|---|
| 連続稼働時間 | 64時間（無人） | 8〜16時間（有人監視前提） |
| 生産貢献台数 | 17,625台 | 数百〜数千台で「実用化」判断 |
| 成功率 | 99.99％ | 99.5〜99.9％（人手介入込み） |
| タスク内容 | 部品ピック・配置・ネジ締め・検査・不良排出等の複合作業 | 単一作業（溶接・塗装・搬送等） |
この実証が示すのは、「人型ロボットによる汎用マニピュレーションの量産現場投入が、もはや『研究段階』ではなく『量産導入段階』に入った」 という事実です。AGIBOTは2024年時点で 量産型人型ロボット「Expedition A1」を年産1,000台体制 で製造開始しており、2026年は 3,000〜5,000台 へスケール予定とされています。
3-3 日本製造業が直面する「三つの壁」
AGIBOT実証と国内三社データセット構築を並べて見ると、日本製造業には以下の三つの壁が見えてきます。
| 壁 | 内容 | 対応の方向性 |
|---|---|---|
| 壁1：実データ不足 | 国内工場は「止められない」「撮影許可が下りない」「データ共有文化がない」ため、実エピソードデータが圧倒的に不足 | シミュレーション合成データ（Sim2Real）でカバー、デジタルツイン整備、三社共同データセットへの積極参加・活用 |
| 壁2：人型ロボット「不在」 | 国内大手（ファナック・安川・川崎重工・不二越・デンソーウェーブ等）は 人型ロボットを製品ラインナップに持たない | 人型ロボット参入か、垂直多関節＋移動ベース（AMR）での代替か、戦略的判断が必要。AGIBOT・テスラOptimus・Figure・1X等との提携・対抗検討 |
| 壁3：ハーネス・評価基盤の欠如 | フィジカルAIエージェントの「外側ループ」（タスク分解・安全評価・失敗復旧・人間エスカレーション）を回す基盤が未整備 | MCPベースのロボット制御ハーネス内製、安全規格（ISO 10218/ISO/TS 15066）準拠の評価パイプライン構築 |
特に「壁3」は、ソフトウェア開発の「外側ループ」問題と構造的に同一 です。コード生成エージェントも、ロボット制御エージェントも、「内側ループ（推論・実行）」はモデルが担うが、「外側ループ（計画・評価・記憶・安全・人間連携）」はハーネスが担う というアーキテクチャは共通しています。
4. AIセキュリティ——「Mythos」とハーネス、脆弱性発見の自動化がもたらすパラダイムシフト
4-1 ITmedia AI＋「Mythosがないと守れない」は本当か？
ITmedia AI＋（7月3日）の記事「『Mythosがないと守れない』は本当か？？AIセキュリティの勝負を分ける『ハーネス』とは」は、脆弱性発見AI 「Mythos」 を巡る議論を整理しています。
Mythos は、Google Project Zero等が開発を進める 「コードベース全体を解析し、ゼロデイ脆弱性を自動発見・PoC生成・修正提案まで行うAIエージェント」 です。2026年春時点で一部の組織（Google、Microsoft、一部政府機関等）にアクセスが限られており、「Mythos級のAIにアクセスできない企業は、もう守れない」という脅威論が広がりました。
しかし記事は、「勝負を分けるのはアクセスの有無ではなく、ハーネス（外側ループ）の設計だ」 と論じます。理由は三点。
- Mythosも「内側ループ」に過ぎない──脆弱性スキャン・PoC生成という「タスク実行」は高速化できるが、「どのリポジトリを優先スキャンするか」「誤検知をどうフィルタするか」「修正をどうステージングし、人間レビューへ回すか」「修正後の回帰テストをどう自動化するか」は 外側ループ（ハーネス）の設計次第
- オープンソース代替が急速に追いついている──Hacker News（7月3日）で紹介された 「Anatomy of Persistent Memory's 3 Layers: Comparing ContextNest, Mem0 and Zep」 は、エージェントの長期記憶・文脈管理を比較検証しており、Mythosの核心技術（長大コンテキスト＋ツール連携＋反復修正）はオープンスタックでも再現可能 になりつつある
- 「守る側のハーネス」こそが差別化要因──攻撃側（脆弱性発見）が自動化されれば、防御側も 「継続的スキャン→優先度付け→自動修正PR作成→カナリアデプロイ→監視」というハーネスを回せるか で決まる
4-2 日本企業のセキュリティハーネス成熟度
日本企業の多くは、まだ 「定期診断（年1〜2回）」→「報告書受領」→「手動修正」→「再診断」 という 手動外側ループ で運用しています。これに対し、先進的な組織では以下の 自動化ハーネス を構築し始めています。
| ハーネス機能 | 実装例 | 日本での採用状況 |
|---|---|---|
| 継続的コードスキャン（SAST/DAST/SCA） | GitHub Advanced Security、GitLab SAST、Snyk、Semgrep CI | 導入済み多いが「アラート放置」課題大 |
| AIによる誤検知フィルタ・優先度付け | カスタムLLMエージェント、CodeQL＋LLM、Semgrep Assistant | PoC段階、本番運用は稀 |
| 自動修正PR生成・提案 | GitHub Copilot Autofix、Snyk Fix、カスタムエージェント | 導入開始、信頼性検証中 |
| 修正後カナリアデプロイ・監視 | Argo Rollouts＋Prometheus＋Grafana、LaunchDarkly | インフラ成熟組織で導入 |
| 全工程を繋ぐオーケストレータ | 独自開発（Level 2相当）、または Manufact等MCP基盤活用 | ほぼ未着手 |
結論：「Mythosアクセス権」を得ることより、「自社のセキュリティハーネスをLevel 2まで引き上げること」の方が、日本企業にとって現実的かつ効果的 です。特に MCPベースでセキュリティツール群を統合し、エージェントが「スキャン→判断→修正→検証」を自律回転できる基盤 を作ることが、2026〜2027年の勝負所になります。
5. 日本企業がいま取るべき三つのアクション
以上の三軸（開発ハーネス・MCP・フィジカルAI／セキュリティハーネス）を統合すると、日本のSIer・ユーザー企業・製造業が 2026年下半期〜2027年にかけて優先すべきアクション は以下の三つに集約されます。
なお、AIエージェントの実装基盤としての「ハーネス」概念については、先行記事 「AI の『物理層』時代——カスタムチップ、ゲーム学習、電力問題が描くハードウェア革命」 でも、ハードウェア・インフラレイヤーでの基盤内製の重要性を論じており、今回の文脈とも接続します。
アクション1：外側ループ（ハーネス）を「内製資産」として定義し、予算・人員を確保する
| 具体施策 | 期限 | 担当 | KPI |
|---|---|---|---|
| 社内ハーネス基盤チームを新設（または既存AI推進室を再編） | 2026年Q3 | CTO/CDO直轄 | チーム立ち上げ完了 |
| ハーネス要件定義（タスク分解・評価・記憶・MCP連携・人間エスカレーション） | 2026年Q3〜Q4 | ハーネスチーム＋現場エンジニア | 要件書完成、ステークホルダー合意 |
| パイロット：リポジトリ10本で「コード生成→レビュー→マージ」をハーネスで自動回転 | 2026年Q4〜2027年Q1 | ハーネスチーム＋開発部門 | リードタイム30％短縮、レビュー負荷50％削減 |
| 本番展開：全リポジトリへ水平展開、フィジカルAI・セキュリティへ横展開 | 2027年Q2〜 | ハーネスチーム＋各事業部 | 対象リポジトリ100％、フィジカルAI/セキュリティ統合 |
予算感：大手SIer・ユーザー企業で 初年度5〜10億円（人員10〜20名＋インフラ＋ライセンス）、中堅で 1〜3億円（人員3〜5名＋マネージドサービス活用） が目安です。「生成AI導入予算」から「ハーネス内製予算」へ 予算項目を振り替える 決断が経営層に求められます。
アクション2：MCP戦略を「ハイブリッド（自社ホスト＋PaaS消費）」で確定し、初期サーバ3〜5本を年内に立ち上げる
| MCPサーバ | 対象業務・データ | ホスト方式 | 開発担当 | 目標公開日 |
|---|---|---|---|---|
| 基幹システム検索・参照 | ERP、MES、PLM、SCM等のマスタ・トランザクション | オンプレミス／プライベートクラウド（B） | 内製（ハーネスチーム） | 2026年Q4 |
| 設計・製造データアクセス | CAD/BOM/CAE/検査データ、工場IoTセンサーデータ | オンプレミス／エッジ（B） | 内製＋OTベンダー協業 | 2027年Q1 |
| ドキュメント・ナレッジ検索 | Confluence、SharePoint、社内Wiki、過去PJ資料 | PaaS消費（C） または SaaS連携（A） | 情シス＋ベンダー | 2026年Q3 |
| チケット・ワークフロー操作 | Jira、ServiceNow、Redmine、Backlog等 | SaaS公開MCP消費（A） | 情シス | 2026年Q3 |
| セキュリティツール統合 | SAST/DAST/SCA/コンテナスキャン/脅威インテリジェンス | ハイブリッド（B/C） | セキュリティチーム＋ハーネスチーム | 2027年Q1 |
技術的留意点：MCPサーバ実装は Python（FastMCP）または TypeScript（MCP SDK） が標準です。認証は OAuth 2.1＋mTLS、監視は OpenTelemetry＋Prometheus で統一し、ハーネス側から 統一インターフェースで呼び出せる ようにします。Manufact等PaaSを使う場合も、 自社ホスト版と同一インターフェース でラップしておくことで、将来的な移行・共存を容易にします。
アクション3：フィジカルAI・セキュリティハーネスを「共通基盤」として統合し、製造現場・開発現場の両面で回す
| 統合ポイント | 内容 | 実現アプローチ |
|---|---|---|
| 共通オーケストレータ | LangGraph、AutoGen、MagenticLite、独自実装のいずれかを 全社標準 に固める | ハーネスチームが評価・選定し、テンプレート化して各ドメイン（開発・製造・セキュリティ）へ配布 |
| 共通メモリ層 | エピソード記憶（タスク履歴）、セマンティック記憶（ナレッジ・仕様書）、手続き記憶（ワークフロー定義）を ベクトルDB＋グラフDB＋RDB で統合管理 | ContextNest、Mem0、Zep等の比較検証（Hacker News記事参照）を経て選定、マルチテナント対応 |
| 共通評価・安全ゲート | コード品質ゲート、ロボット動作安全ゲート、脆弱性修正検証ゲートを 統一インターフェース で定義 | ハーネス基盤に「評価プラグイン」機構を実装、ドメイン別プラグインを追加可能に |
| 共通人間エスカレーション | Slack/Teams/メール/電話/現場アンドン等、チャネルを問わず 「人間判断要求」を統一フォーマット で発行・追跡 | MCPツールとして「エスカレーション送信」「応答受信」「タイムアウト処理」を標準実装 |
組織的インパクト：この統合により、「開発部門」「生産技術部門」「情報セキュリティ部門」「DX推進部門」が共通のハーネス基盤上でエージェントを開発・運用する 組織になります。従来の縦割り予算・縦割り組織では実現できないため、CTO/CDO直轄の「エージェント基盤室（仮称）」を横断組織として設置し、予算・人事権を持たせる ガバナンス改革がセットで必要です。
6. まとめ——「モデル選定」から「基盤内製」へ、日本企業の勝負所
2026年夏、AIをめぐる構造変化の核心は 「モデルの賢さ競争」から「ハーネス・プロトコル・データの基盤競争」へのシフト にあります。
| 旧パラダイム（〜2025前半） | 新パラダイム（2025後半〜） |
|---|---|
| どのLLMを使うか（GPT-5 vs Claude 4 vs Gemini 3 vs 国産） | どうエージェントを回すか（ハーネス設計・運用） |
| プロンプトエンジニアリングで性能を引き出す | MCPでツール・データを標準化し、エージェントに「手足」を与える |
| 生成AI導入プロジェクト（PoC量産） | エージェント基盤内製・運用（継続的投資） |
| セキュリティは定期診断・手動修正 | セキュリティハーネスで継続的スキャン・自動修正・検証を回す |
| ロボットは教示再生・単機能自動化 | フィジカルAIデータセット＋シミュレーション＋ハーネスで汎用マニピュレーション |
この新パラダイムにおいて、日本企業が持つ強み（現場データ・製造ノウハウ・品質文化・長期雇用による暗黙知継承） を活かせるのは、「基盤を内製し、現場に合わせて継続改善し続ける」 道を選んだ場合のみです。
- SIer は、「生成AI導入支援ベンダー」から 「エージェント基盤内製パートナー（ハーネス共同開発・運用受託）」 へビジネスモデル転換を迫られます。
- ユーザー企業（製造・金融・流通・インフラ） は、「AIツール購入」から 「ハーネス・MCP・データセットを自社資産として内製・蓄積」 へ予算・組織をシフトさせる必要があります。
- ロボット・FAメーカー は、国内三社のデータセット共同構築に 「競争領域・非競争領域の切り分け」で参画 し、人型ロボット参入・提携の是非を 「ハーネス内製力」を前提に判断 する必要があります。
「コードを書く」から「ループを回す」へ。 この言葉は、ソフトウェア開発だけでなく、製造現場、セキュリティ運用、業務プロセス全般に適用される 2026年以降の日本企業共通の命題 です。
いま、その 外側ループ（ハーネス）の第一歩を、自社で踏み出せるかどうか。それが、向こう5〜10年の競争力を分ける分水嶺になるはずです。
参考文献・情報源
- ITmedia AI＋「ソフトウェアエンジニアの仕事は『ループを書くこと』になる──内側ループと外側ループ（ハーネス）入門」（2026年7月3日）
- ITmedia AI＋「『Mythosがないと守れない』は本当か？？AIセキュリティの勝負を分ける『ハーネス』とは」（2026年7月3日）
- ITmedia AI＋「国内大手ロボットメーカー3社が協力、『フィジカルAI』向けデータセット構築へ」（2026年7月2日）
- ITmedia AI＋「人型ロボットが工場で稼働する様子を6日間生配信、作業成功率99.99％をうたう 中国メーカー」（2026年7月2日）
- ITmedia AI＋「楽天、AIエージェントで運用コスト・遅延30％低減──『単発質問』超えたワークフロー統合で成果」（2026年6月30日）
- ITmedia Enterprise「日立、ミッションクリティカル領域におけるAI活用を支援『Hitachi iQ Studio』の3つの特徴」（2026年7月2日）
- ThinkIT「【利用率から運用設計へ】生成AIをめぐる『競争軸』と『課題』の変遷」（2026年7月2日）
- Hacker News「Show HN: TaskPeace – a task queue my AI coding agents pull work from over MCP」（2026年7月3日）
- Hacker News「Anatomy of Persistent Memory's 3 Layers: Comparing ContextNest, Mem0 and Zep」（2026年7月3日）
- Hacker News「Gemini Code Assist will be shut down on July 17」（2026年7月3日）
- TechCrunch「Mark Zuckerberg tells staff that AI agents haven't progressed as quickly as he'd hoped」（2026年7月2日）
- TechCrunch「Anthropic is discussing a new custom chip with Samsung」（2026年7月2日）
- Google News RSS「国産AI、ソフトバンク設立の新会社に3873億円支援へ 経産省」（朝日新聞、2026年6月30日）
- Google News RSS「『AI格差』拡大に警鐘 国連専門家パネルが報告書」（時事ドットコム、2026年7月2日）
- Google News RSS「日本版AI法の概要と企業への影響」（BUSINESS LAWYERS、2026年6月1日）
- Armin Ronacher "Software engineering becomes writing loops"（原典記事）
本記事は、2026年7月3日〜4日時点の公開情報をもとに構成しています。記載内容は執筆時点のものであり、最新の動向とは異なる場合があります。投資・導入判断の際は一次情報をご確認ください。
✍️ この記事を書いた人
スマートホーム愛好家として 50 台以上の IoT 製品を自宅でテストしてきた実務経験を持つ。HEMS、音声アシスタント、スマートロック、カメラセンサーなど、住まいに関わるあらゆる IoT 機器の導入・運用・比較評価を専門とする。