アーキテクチャ

「ハーネスエンジニアリング」という言葉がAIエージェント界隈でバズワード化し、意味の希薄化が起きている。watany氏のZenn記事「AIエージェントの"ハーネス"に関わる混乱と私見」は、この混乱を「内側のハーネス」と「外側のハーネス」という軸で整理している。本記事は、その整理を元に「ハーネス」という言葉の意味的な分裂を読み解く。 内側のハーネス（Internal Harness） 開発者・プラットフォーム視点の定義。 LangChain: 「エージェント = モデル + ハーネス」という等式を掲げ、自社をハーネス構築のプラットフォームとして位置づける Anthropic: 長時間実行されるLLM処理の仕組みとして定義。ステートレスなモデル呼び出し間でセットアップスクリプトやGitの履歴などのコンテキストを引き継ぐ機構を指す。生成Agentと評価Agentからなる二段階のマルチエージェント構成も含む 内側のハーネスの議論はベンダーロックインを促す傾向があり、プラットフォームとしての優位性を訴求する文脈で使われやすい。 外側のハーネス（External Harness） ユーザー・実践者視点の定義。 Mitchell Hashimoto: 「AIエージェントが同じミスを繰り返さないように設計する」という実践的なアプローチ。開発者の日常的な課題に根ざした定義 OpenAI: メンテナブルで読みやすいエージェント出力の設計を重視し、将来の実行エージェントが参照できる保守可能な成果物の生成を重視する 外側のハーネスはベストプラクティスの共有が主眼で、特定プラットフォームへの依存を前提としない。 なぜ混乱するのか Takuto Wada（@t_wada）氏はこの記事を紹介し、同じ言葉なのにスコープが違うのは言う側のポジションで意味合いがズレているのが理由だと指摘している。 ベンダーは「ハーネス」を自社製品の文脈で語り、実践者は「ハーネス」を運用上の問題解決として語る。どちらも正しい文脈を持ちながら、同一の言葉が異なる聴衆に向けて発信されている。 まとめ 「ハーネス」という言葉を聞いたとき、それが誰の視点からの発言かを意識するだけで、議論の意図がずっと明確になる。 プラットフォーム・フレームワーク文脈 → 内側のハーネス（統合基盤としての役割） 実践・運用文脈 → 外側のハーネス（エラー再発防止・出力品質の設計） AIエージェント開発が加速する中、用語の解像度を上げることは技術コミュニティ全体の生産性に直結する。watany氏の整理は、この問題に対して実践的な視点を提供している。 参考: AIエージェントの"ハーネス"に関わる混乱と私見 — watany (Zenn) t_wada氏のポスト (X)

2026年4月7日、AWSがAmazon S3 Filesを一般提供（GA）しました。S3バケットをNFS v4.1/v4.2のファイルシステムとしてマウントできる機能で、EC2・EKS・ECS・Lambdaのいずれからでも利用できます。 本記事は、ikenyal氏のZenn記事「S3 Filesで消えるアーキテクチャ層、生まれるアーキテクチャ」を参照しながら、S3 Filesが既存のアーキテクチャにどう影響するかを整理します。「何が設定できるか」ではなく「何が不要になり、何が可能になるか」にフォーカスします。 S3 Filesが解こうとしている問題 たとえば、MLチームが学習データの前処理をする場面を考えましょう。元データはS3に置いてあり、pandasで読み込んで加工したい場面です。 pd.read_csv("s3://my-bucket/data.csv") と書けますが、内部ではboto3がGETリクエストを発行してメモリに読み込んでいます。手元の open("./data.csv") とは根本的に異なるI/Oモデルです。 規模が大きくなると、これは「パイプラインのアーキテクチャ課題」になります。 S3からEFS/EBSにコピー → 処理 → 結果をS3に書き戻す この「中間のコピー層」は本来やりたい処理ではなく、ストレージのI/Oモデルの違いを埋めるためだけに存在しています。 S3 Filesはこのギャップそのものを解消します。アプリケーションからS3のデータはローカルのディレクトリに見えます。 1 2 3 # S3 Filesを使うと pd.read_csv("/mnt/s3files/data.csv") # S3のオブジェクトが読まれる df.to_csv("/mnt/s3files/result.csv") # 変更が自動的にS3にコミットされる FUSEベースのツールとの違い 「S3をマウントできる」と聞いて、Mountpoint for Amazon S3やgcsfuseを思い浮かべる方も多いでしょう。S3 Filesは内部構造がまったく異なります。 FUSEベースのツールは、S3 APIの上にファイルシステムの振る舞いを「エミュレーション」するアプローチです。ファイルの一部だけを書き換えるような操作がサポートされず、空ディレクトリの扱いに不整合が出ることもあります。 S3 Filesはエミュレーションではなく、EFS（Elastic File System）という本物のNFSファイルシステムをS3に接続しています。二つの異なるシステムが共存し、その間に明示的な同期レイヤーがある構造です。 「stage and commit」モデル ファイルシステム上での変更は即座にS3に反映されるのではなく、約60秒ごとにまとめてS3へPUTされます（「commit」）。逆に、S3側でオブジェクトが更新された場合は通常数十秒以内にファイルシステム側に反映されます。 これは明確なトレードオフです。「リアルタイムに同期される共有ファイルシステム」ではなく、「数十秒の遅延を許容する代わりに、ファイルとオブジェクトの両方のセマンティクスを壊さない」設計です。 消えるアーキテクチャ層 1. S3 → EFS/EBSのステージングパイプライン 100GBの学習データを処理する場合、従来の手順は： S3からEBSにダウンロード（数分かかる） データを処理する 結果をS3にアップロード EBSボリュームをクリーンアップ やりたい処理は2番だけです。S3 Filesでは、S3プレフィックスをマウントするだけで処理スクリプトはそのまま /mnt/s3files/ のファイルを読み書きします。ダウンロード・アップロード・クリーンアップのステップが消えます。 ...

概要 Vercel が推進する FdI は、ビルド時にソースコードを解析してインフラ構成を自動導出。従来の IaC ではインフラを明示的に定義する必要があるが、FdI では開発者が「何を作るか」に集中し「どこにデプロイするか」を考える必要がない。 ソース記事 Vercel とインフラエンジニア — 2026-03