記事一覧へ
1940年代初頭、ベル研究所は当時世界で最も複雑な技術システムである全国電話ネットワークを構築していました。何百万ものスイッチ、ケーブル、リレー、オペレーターが協調して動作する必要がありました。エンジニアたちは80年間の教訓となる何かを発見しました：個々のコンポーネントを最適化してもシステム全体を最適化することはできない。全体の動作（通話ルーティング、信頼性、容量、コスト）は部品の相互作用から生まれました。彼らはコンポーネント間の相互作用に焦点を当てた規律を必要としていました。
彼らはそれをシステムズエンジニアリングと呼びました。
エージェント型ソフトウェアのエコシステムは、この規律を生み出した同じ過ちを繰り返しています。現在のハーネスエンジニアリングの流れは、ストレージとメモリにファイルシステムを使うよう求め、次にその制限を回避しようとしてデータベース上に仮想化ファイルシステムを構築します。バッシュを汎用ツールとして使うよう求め、次にセキュリティを処理するためにリクエストごとのサンドボックスを強制します。これらはシステム全体を考慮せずに一部を最適化している症状です。そして私たちは、これが正しいアプローチかどうかを一瞬考えることなく、それを受け入れています。
## ソフトウェアエンジニアリングはシステムズエンジニアリング
コーディングエージェントはコードを書くハードルを下げましたが、本番ソフトウェアの要件は下げていません。ソフトウェアエンジニアリングは、常にシステムズエンジニアリングであり、エージェント型ソフトウェアを構築するなら、システムはこの5つの層を橋渡しする必要があります：
**1. エージェントエンジニアリング：** エージェントまたはマルチエージェントのロジックと実行フロー。
モデル、システム指示、ツール設定、ハンドオフ、コンテキスト管理、可観測性。ここでエージェントが何をするか、どのように動作するか、どのように応答するかを定義します。エージェントの動作は可能な限り決定論的で、そうでない場合は観測可能であるべきです。
**2. データエンジニアリング：** エージェントはアクセスできるコンテキストの質に依存し、コンテキストは本質的にデータに過ぎません。メモリ、ストレージ、知識：すべてデータエンジニアリングの原則で管理されるべきです。これは、適切に設計されたスキーマ、構造化クエリ、高速読み書きのためのデータベース、長期ストレージのためのオブジェクトストレージ、そして知識とメモリを最新に保つパイプラインを意味します。パターンは数十年前からあります。それを活用してください。
**3. セキュリティエンジニアリング：** 認証、RBAC、ガバナンス、データ分離、監査証跡。
エージェントの機能はツールで定義され、それらのツールはJWT認証のパーミッションでスコープされるべきです。読み取り専用アクセスはプロンプト命令ではなく、ツール設定です。アクションには承認ティアが必要です：読み取りは自由に実行、書き込みはユーザー承認が必要、機密操作は管理者の承認が必要です。ほとんどのアクションはログに記録され、製品のライフタイム全体でクエリ可能であるべきです。
そして、リクエストを分離してください。一人のユーザーのコンテキストが別のユーザーにブリードすることは、バグではなくデータ漏洩です。深刻な結果をもたらし、ユーザーデータを保護する法律があります。したがって、共有サンドボックス上のファイルシステムバックドメモリは良いアイデアではないかもしれません。
**4. インターフェースエンジニアリング：** ユーザーや他のエージェントがエージェントにアクセスする方法。
REST API、Slack、MCPサーバー、ターミナル。以前は1つのAPIと1つのクライアントがありました。今では複数のサーフェスがあり、それぞれに独自のアイデンティティシステムがあります。SlackのユーザーIDは製品のユーザーIDではありません。別のエージェントとして認証するMCPクライアントは人間ユーザーではありません。インターフェースエンジニアリングは、認証、ポリシー、アクセス制御がエージェントが到達可能なすべてのサーフェスで一貫して保たれることを確認することです。
**5. インフラエンジニアリング：** ソフトウェアの実行とスケーリング方法。コンテナ、クラウドデプロイ、水平スケーリング。一般的にDevOpsと呼ばれます。
良いニュース：95%は他のサービスを実行するのと同じです。既存のパターンを再利用すれば、うまくいきます。5%の違い：エージェントのリクエストには時間がかかる（ロードバランサーのタイムアウトを増やす）、応答はストリームされる（SSEまたはWebSocketを計画する）、最良のエージェントはプロアクティブ（スケジュールタスク、バックグラウンド実行）。これらは何も新しくありません。
AIエンジニアにとっての重要な気づきは、エージェント型ソフトウェアはただの通常のソフトウェアであり、ビジネスロジックがエージェントに置き換えられ、インターフェースがリクエスト/レスポンスから複数のサーフェスをまたぐストリーミングに変わるということです。
システムズエンジニアリングはこれらの部品を協調させる規律であり、機能するエージェント型ソフトウェアを構築するための鍵です。
ソフトウェアをシステムの視点から見ると、正しい決断が明らかになります——MCP vs CLIの議論をやめ、エージェントに適切にスコープされたツールを与え、ファイルではなくデータベースにセッション・メモリ・知識を保存します。
一つの層を独立して設計すると、残りのシステムに連鎖する制約を引き継ぎ、その制約にパッチを当てるために時間とリソースを無駄にします。システムの視点から設計すると、各層が他の層を強化します。
## システムズエンジニアリングの実践
これほど大きな主張をして、実際のコードを示さないわけにはいきません。
Dashはオープンソースの自己学習型データエージェントです。平易な英語で質問を投げると、SQLを書き、実行し、数字が意味することを教えてくれます。クローンして適応できるほどシンプルで、5つの層すべてを実証できるほど本格的です。
Dashの各層の仕組みは以下のとおりです：
**エージェントエンジニアリング**
Dashはエージェントのチームです。リーダーが2人のスペシャリストにリクエストをルーティングします：データをクエリするアナリスト（読み取り専用）とビューやサマリーテーブルなどの計算アセットを構築するエンジニア。各スペシャリストは異なる機能に接続された同じツールタイプを取得します。アナリストのSQLツールは読み取り専用データベースエンジンに接続されます。エンジニアのSQLツールは単一のスキーマにスコープされた書き込み可能なエンジンに接続されます。同じインターフェース、異なるパーミッション、プロンプトではなく設定によって決定されます。指示はテーブルメタデータとビジネスルールから実行時にアセンブルされます。
**データエンジニアリング**
コンテキストの6つの層とラーニングのためのツール。
SQLを書く生のLLMはすぐに壁に当たります：スキーマに意味がなく、型が誤解を招き、部族知識が欠如し、ミスから学ぶ方法がありません。Dashはこれを6つのグラウンデッドコンテキストの層で解決します：
テーブルメタデータ（スキーマ、カラム、リレーションシップ）
人間のアノテーション（メトリクス、定義、ビジネスルール）
クエリパターン（動作することが既知のSQL）
機関知識（ドキュメント、Wiki）
ラーニング（エラーパターンと発見された修正）
ランタイムコンテキスト（ライブスキーマインスペクション）。
これらの層は2つのシステムに供給されます：
最初はキュレーションされた知識：PostgreSQLに読み込まれたテーブルスキーマ、検証されたクエリ、ビジネスルール。
2番目は発見されたラーニング：エージェントが問題に当たったときに保存し、将来のクエリで想起するエラーパターンと修正。
ラーニングループはシンプルです：エージェントがクエリを実行し、型エラーを得て、修正を診断し、保存します。次に同様のカラムを見たとき、最初から正しく処理します。そしてエンジニアが新しいビューを作成すると、スキーマとサンプルクエリをナレッジベースに記録します。アナリストは次の検索でそれを発見し、使い始めます。クエリ100はクエリ1より優れています——モデルが改善されたからではなく、データ層が改善されたからです。
**セキュリティエンジニアリング**
システムによって強制され、プロンプトではない。
本番のDashはJWT検証を使用したRBACを使用します。すべてのクエリは`user_id`にスコープされます。評価スイートはこれらの境界を直接テストします：エージェントに資格情報の漏洩、破壊的なSQLの実行、スキーマ境界の越境を促し、それができないことを検証します。
セキュリティは層をまたいでテストされたシステムプロパティです。アナリストの読み取り専用アクセスはPostgreSQLの接続パラメーターです。データベース自体は、モデルが何を生成するかに関わらず書き込みを拒否します。エンジニアは書き込みができますが、単一のスキーマのみ：クエリレベルのガードがソースデータを対象とする操作をブロックします。
**インターフェースエンジニアリング**
DashはREST API、Slack bot、Web UI、CLIとして利用可能です。各サーフェスはアイデンティティを異なる方法で処理します：Slackはスレッドタイムスタンプをセッションにマッピングし、APIは本番でJWTトークンを使用します。しかし4つすべてが同じエージェント、同じツール、同じ知識に到達します。
エージェントはどのサーフェスから呼ばれているか知らないため、認証とアクセス制御はすべてのサーフェスで保たれる必要があります。
**インフラエンジニアリング**
最小限のPythonコンテナ。ローカル開発のためのDocker Compose。任意のクラウドにデプロイ。標準のASGIサーバーを通じてSSEによるストリーミング。他のサービスと同一の95%は同一です。5%の違い（長いタイムアウト、ストリーミング、スケジュールタスク）は標準ツールで処理されます。
クローンして`docker compose up`を実行するだけで、システム全体が立ち上がります。
ワンコマンド、5つの層、システムズエンジニアリングのおかげで機能する製品です。
参考リンク：https://github.com/agno-agi/dash
harness-designagent-opssecurity
AIエージェントに必要な5層システム設計
♥ 894↻ 104
原文を表示 / Show original
In the early 1940s, Bell Labs was building the national telephone network, the most complex technical system in the world at the time. Millions of switches, cables, relays, and operators had to work together. The engineers discovered something that would become an 80-year-old lesson: you can't optimize a system by optimizing individual components. The behavior of the whole (call routing, reliability, capacity, cost) emerged from how the parts interacted. They needed a discipline focused on the interactions between components.
They called it systems engineering.
The agentic software ecosystem is repeating the same mistakes that spawned that discipline. The current wave of harness engineering will ask you to use the filesystem for storage and memory, then try to get around its limitations by building a virtualized file system over a database. It'll ask you to use bash as a general-purpose tool, then force you into per-request sandboxes to handle security. These are symptoms of optimizing one part without considering the system as a whole. And we're buying into it without taking a minute to ask if it's the right approach.
Software Engineering Is Systems Engineering
Coding agents have lowered the barrier to writing code, but they haven't lowered the requirements of production software. Software engineering is, and has always been, systems engineering and if you're building agentic software, your system needs to bridge these five layers:
1. Agent Engineering: Your agent or multi-agent logic and execution flow.
Model, system instructions, tool configurations, handoffs, context management, observability. This is where you define what your agent does, how it runs and how it responds. Your agent's behavior should be deterministic where possible and observable where it isn't.
2. Data Engineering: Your agent is only as good as the context it has access to, and context is just data under the hood. Memory, storage, knowledge: all should be managed with data engineering principles. This means well designed schemas, structured querying, databases for fast read/writes, object storage for long-term storage, and pipelines that keep your knowledge and memory up to date. The patterns are decades old. Use them.
3. Security Engineering: Auth, RBAC, governance, data isolation, audit trails.
Your agent's capabilities are defined by its tools, and those tools should be scoped with JWT-backed permissions. Read-only access IS NOT a prompt instruction, it's a tool configuration. Actions should have approval tiers: reads run freely, writes need user approval, sensitive operations need admin sign-off. Most actions should be logged and queryable for the life of the product.
And please, isolate requests. One user's context bleeding into another's is a data breach, not a bug. It has serious consequences and there are laws protecting user data. So filesystem backed memory on a shared sandbox might not be a good idea.
4. Interface Engineering: How users and other agents reach your agent.
REST API, Slack, MCP server, terminal. In the old world, you had one API and one client. Now you have multiple surfaces, each with its own identity system. A Slack user ID is not your product's user ID. An MCP client authenticating as another agent is not a human user. Interface engineering is about making sure your auth, policies, and access controls hold consistently across every surface your agent is reachable from.
5. Infrastructure Engineering: How you run and scale your software. Containers, cloud deployment, horizontal scaling. Generally called DevOps.
The good news: 95% of this is identical to running any other service. Re-use existing patterns, they'll serve you well. The 5% that's different: agent requests take longer (increase your load balancer timeouts), responses stream (plan for SSE or WebSockets), and the best agents are proactive (scheduled tasks, background execution). None of this is new.
The key unlock for AI engineers is realizing that agentic software is just regular software, with the business logic replaced by agents, and interfaces going from request/response to streaming across multiple surfaces.
Systems engineering is the discipline of making these parts work together, and is the key to building agentic software that works.
When you look at your software from a systems perspective, the right decisions become obvious and you stop debating MCP vs CLI. You give your agent well-scoped tools, not unfettered bash access. You store sessions, memory, and knowledge in a database, not files.
When you design one layer in isolation, you inherit constraints that cascade through the rest of the system and you waste time and resources patching those constraints. When you design from the system's perspective, each layer reinforces the others.
Systems Engineering in Practice
I can't make a claim this big and not give you working code.
Dash is an open-source, self-learning data agent. You ask it questions in plain English, it writes SQL, runs it, and tells you what the numbers mean. Simple enough to clone and adapt. Real enough to demonstrate all five layers.
Here's how each layer works in dash:
Agent Engineering
Dash is a team of agents. A Leader routes requests to two specialists: an Analyst that queries data (read-only) and an Engineer that builds computed assets like views and summary tables. Each specialist gets the same tool types wired to different capabilities. The Analyst's SQL tools connect to a read-only database engine. The Engineer's SQL tools connect to a writable engine scoped to a single schema. Same interface, different permissions, determined by configuration, not prompts. Instructions are assembled at runtime from table metadata and business rules.
Data Engineering
Six layers of context, and tools for learning.
Raw LLMs writing SQL hit a wall fast: schemas lack meaning, types are misleading, tribal knowledge is missing, there's no way to learn from mistakes. Dash solves this with six layers of grounded context:
Table metadata (schema, columns, relationships)
Human annotations (metrics, definitions, business rules)
Query patterns (SQL that is known to work)
Institutional knowledge (docs, wikis)
Learnings (error patterns and discovered fixes)
Runtime context (live schema inspection).
These layers feed two systems:
The first is curated knowledge: table schemas, validated queries, and business rules loaded into PostgreSQL.
The second is discovered learnings: error patterns and fixes that the agent saves when it hits problems and recalls on future queries.
The learning loop is simple: the agent runs a query, gets a type error, diagnoses the fix, saves it. Next time it sees a similar column, it gets it right the first time. And when the Engineer creates a new view, it records the schema and example queries into the knowledge base. The Analyst discovers it on the next search and starts using it. Query 100 is better than query 1, not because the model improved, but because the data layer got better.
Security Engineering
Enforced by the system, not the prompt.
Dash in production uses RBAC with JWT verification. Every query is scoped to `user_id`. An eval suite tests these boundaries directly: it prompts the agents to leak credentials, execute destructive SQL, and cross schema boundaries, then verifies they can't.
Security is a system property tested across layers. The Analyst's read-only access is a PostgreSQL connection parameter. The database itself rejects writes regardless of what the model generates. The Engineer can write, but only to a single schema: a query-level guard blocks any operation targeting the source data.
Interface Engineering
Dash is available as a REST API, a Slack bot, a web UI, and a CLI. Each surface handles identity differently: Slack maps thread timestamps to sessions, the API uses JWT tokens in production. But all four hit the same agents, same tools, same knowledge.
Your auth and access controls need to hold across every surface, because the agent doesn't know which one it's being called from.
Infrastructure Engineering
Minimal python container. Docker compose for local development. Deploy to your cloud of choice. Streaming via SSE through a standard ASGI server. The 95% that's identical to any other service is identical. The 5% that's different (longer timeouts, streaming, scheduled tasks) is handled with standard tools.
You can clone it, run `docker compose up`, and have the entire system.
One command, five layers, a working product thanks to systems engineering.
Here's the link for reference: https://github.com/agno-agi/dash