Ichizoku

企業向けAIエージェントの開発・導入支援、FDE（フォワードデプロイドエンジニア）育成プログラムを提供しています。

・AIエージェントの設計・開発・本番運用
・ハルシネーション対策、生成AIの精度向上
・FDE育成プログラム （企業研修）
・米国企業との連携による最新

[Ichizoku @Ichizokuagents]

FDEは、SESともITコンサルとも違います。

FDE（Forward Deployed Engineer）とは、顧客の業務現場に入り、課題の特定からAIの実装、本番運用までを担うエンジニアです。コードを書くだけでなく、構築したシステムが業務の成果につながるところまで責任を持ちます。

・FDEの仕事内容（6つのステップ）
・SES、ITコンサル、SIerとの違い
・FDEに必���なスキル
・社内でFDEを育てる方法

基本から、実際の案件での動き方まで、まとめました。
https://t.co/xkyY8gXIn4

#FDE #AIエージェント #エンタープライズAI

[Jay Revels @jgrevels]

FDEとして成果を出すために、最も大事なスキルは何か。

FDEの定義は会社によってさまざまですが、多くの場合に共通するのは「顧客と話すこと」と「どう解決するかを決めること」だ��いう指摘に、私も同感です。

技術力以上に差がつくのは、顧客の言葉の裏にある本当の課題を見極め、何を作るべきかを自ら判断する力です。FDEを育てるうえでも、ここが最も重要なポイントだと考えています。

@Ichizokuagents #FDE育成プログラム

[Ichizoku @Ichizokuagents]

「エージェントに記憶を持たせるなら、とにかく全部保存しておけばいい」

と考えがちですが、Anthropicのエンジニアリングブログでは、むしろ逆の結果が示されていました。

ゲーム「ポケットモンスター 赤」を使ったプレイ検証では、次のような差が出たそうです。

・Sonnet 3.7：225フォル��に413ファイルを保存し、獲得バッジは1個
・Fable 5：2フォルダに9ファイルとglobal.mdだけを保存し、獲得バッジは4個

画面を見ればわかる情報まで保存すると、記憶はすぐに古くなり、必要な情報を探すだけでも時間がかかります。残すべきなのは、作戦や検証済みのルールなど、記録しなければ失われる情報です。

また、「失敗だけを記録する」のようにルールを決めてしまうと、性能の高いモデルほど、かえって記憶の効果が下がったそうです。さらに、作業ログと照らし合わせて記憶を見直す「dreaming」によって、誤ったメモを修正できることも示されています。

業務エージェントの記憶を設計するなら、「何を保存するか」を考える前に、「何を保存しないか」を決めることをおすすめします。

[Anthropic @AnthropicAI]

Memory is what allows Claude to learn from experience. In a new Engineering Blog post, we share how “dreaming” helps Claude organize what it’s learned, correct its mistakes, and find what it needs more easily the next time. https://t.co/uUEN4bNkr9

[Jay Revels @jgrevels]

エンジニアリングマネージャーの皆様へ

FDE不足を解消す��には、求人サイトではなく、まず自分のチームに目を向けるべきです。

少ない候補者を高コストで奪い合うのは、その場しのぎにすぎません。

「現場に入る→リリースする→成果を振り返る」

この育成サイクルを繰り返せば繰り返すほど、チームの実力は着実に伸びていきます。

中堅SEを育てず、コストの高い外部の支援を選び続けていると、時間は稼げても組織の力は失われていきます。

FDE育成プログラム：https://t.co/dwAfD7zTQi

#FDE #AI内製化 #エンジニア組織

@Ichizokuagents

[Ichizoku @Ichizokuagents]

企業向けエージェントを本番環境にリリースする前に、私たちは業務チームと一緒に「エージェントを壊す日」を設けています。

セキュリティのペネトレーションテストではありません。日々その業務��担当している人たちに、エージェントが失敗するよう、あえてさまざまなケースを試してもらいます。

- 顧客からの珍しい依頼
- 未入力の項目
- 矛盾するルール
- 月末にしか発生しないケース

見つかった失敗は、リリース前にすべて評価ケースに追加します。

業務チームはエンジニアが想定できなかった失敗を見つけてくれます。

自分たちで壊そうとして見つけた失敗が反映されているからこそ、業務チームはエージェントを信頼できるようになります。

#AIエージェント #エンタープライズAI #Ichizoku

[Ichizoku @Ichizokuagents]

@diizuka ご質問ありがとうございます。その改善ループもFDEの仕事の一部です。 加えてFDEは顧客の現場に入り、どの課題にLLMを使うかを決めるところから、本番運用まで関わります。

[Ichizoku @Ichizokuagents]

ソフトウェア���ンジニアの90%は、Forward Deployed Engineerになれません。

コードが書けないからではありません。課題発見、スコープ定義、信頼構築といった、これまで求められてこなかった力が壁になるからです。

その差をどう埋めるかをまとめました。
https://t.co/mU6piq5I8K

[Ichizoku @Ichizokuagents]

SIerのエンジニアがFDEを目指すとき、足りないのはコード以外の力です。

FDEの育成は5つのステップで進めます。

① 現場での課題発見
② Build-to-Learnによる検証
③ ベンダーに依存しないAIエンジニアリング
④ エンタープライズ環境へのデプロイ
⑤ 運用と事業化

各ステップで作る成果物、次に進む判断基準などをまとめました。
https://t.co/ibjuzWmUkq

#FDE #SIer #AIエージェント

[Ichizoku @Ichizokuagents]

エージェントを本番にリリースした後、私たちがクライアントに毎週報告してい���数字です。

1. 人間の手を介さず、最後まで完了した件数
2. エスカレーションの件数とそれぞれの理由
3. 各業務を担当するチームが節約できた時間

モデルのベンチマークは入っていません。

エージェントを使い続けるかどうかを決めるのは業務責任者であり、判断材料になるのがこれらの数字です。

#AIエージェント #エンタープライズAI #AI導入

[Ichizoku @Ichizokuagents]

エージェントを本格的に使い始めると、最初に詰まるのはモデルではなく、周辺のインフラかもしれません。

OpenAIは、エンジニアとエージェントによるpushやfetchの増加に対応するため、モノレポ用のGitバックエンド「Pando」を開発しました。

ブランチごとの更新を並行して処理し、保存済みのpackfileを多くの読み手で再利用することで、pushの遅延を約80%削減。現在は1日に約1PBのGitデータを配信しているそうです。

Gitの使い方は変えず、裏側の仕組みだけを作り替えている点もポイントです。

エージェントに任せる範囲を広げるなら、モデルだけでなく、GitやCIといった周辺インフラの処理能力も見直す必要があります。

[OpenAI Developers @OpenAIDevs]

We built Pando, a new Git backend for our monorepo, to handle more pushes and fetches without changing how our engineers and agents use Git.

Pando cut push latency by ~80% and now serves nearly a petabyte of Git data a day. We can grow Git capacity alongside agent usage.

[Ichizoku @Ichizokuagents]

Aaron Levie氏は、モデルの能力が向上するほど、業界や業務に特化した取り組みがむしろ進むと述べています。

長時間にわたるタスクへの対応、業界固有のデータの活用、業務に応じたモデルのルーティング、そして「チャット欄に入力するだけ」では済まない業務フローの変革を伴う導入が求められるためです。

企業向けのプロジェクトで、私たちが目にしている現実も同じです。

どの企業も同じモデルを利用できます。差が生まれるのは、各企業のデータ、権限設定、例外処理、そして業務に責任を持つ人たちです。

こうした要素は、製品に最初から組み込まれているわけではありません。現場で作り込むものです。

[Aaron Levie @levie]

The big bitter lesson question in the applied AI layer is that as models get better and better, what is the best way to diffuse that intelligence into an enterprise.

Ironically, I’d argue that as models are getting more capable, and can handle longer running tasks and better tool use, the ability to differentiate on a domain by domain basis goes up instead of down.

When models were quite limited in what they could do, ironically all you could be literally was a “wrapper” because you were effectively delivering tokens back to the user with a custom prompt or some limited RAG.

But in a world of agents using tools, tasks that run on for hours or days, workflows that kick off agents, agent swarms that need to be coordinated against a goal, data sources that are domain specific, model routing that requires domain-specific routing, implementation that requires real change management of the workflow instead of “just type into this chat box”, it’s very very possible that specialization of these systems goes up more.

Obviously this doesn’t apply to everything - the closer you are to the labs core use-cases the tougher this play gets, but I’d argue we’re going to see autonomous systems for a wide range of job functions that weren’t practical to build out before. We’ll see this in security, life sciences, healthcare, finance, manufacturing, and many other fields. Either way going to be a fun and wild couple of years.

[Ichizoku @Ichizokuagents]

基盤モデルはコモディティ化しました。
ChatGPTもClaudeも、競合他社が同じ価格で使えます。

差がつくのは、AIを現場で動かす人材がいるかどうか���す。

自社の業務を知る社員をFDEに育てるほうが、外部採用より定着しやすく、ROIも高くなります。

進め方をまとめました。
https://t.co/g7Ev97QxLK

[Ichizoku @Ichizokuagents]

Ethan Mollick氏は、複数人で使うAIは「グループチャットの段階」を脱する必要があると述べています。

チャットは混乱を招きやすく、すべての情報が全員に見えてしまううえ、AIを既存のチーム内に閉じ込めてしまう、という指摘です。

企業での導入においても、解決策はチャットを改善することではありません。必要なのは、次の点を設計することです。

・エージェントは誰のために動くのか
・誰に何を見せるのか
・仕事の成果をどこに残すのか（チケット、CRMのレコード、承認キューなど）

チームを横断して働くエージェントには、まず権限と引き継ぎの設計が必要です。チャット画面は、最も重要度の低い部分です。

[Ethan Mollick @emollick]

Multiplayer AI needs to move past the group chat phase. Chats are chaotic, everyone sees everything (creating social & management issues), and they're bad for long projects. Worse, they keep AI trapped inside existing teams, when its real promise is working & helping across them.

[Ichizoku @Ichizokuagents]

有名なベンチマークのスコアが高くても、自社のユースケースでうまく動くとは限りません。

Hamel Husain氏が指摘するように、評価そのものが妥当かを確かめる「評価の評価」が必要です。

実際の失敗事例から評価セットを作り、人間によるレビュー結果と評価スコアが整合しているかを定期的に確認する。

この地道なループが、本番で信頼できるエージェントにつながります。

[Hamel Husain @HamelHusain]

BenchmarkGate is a real thing

Don’t blindly trust benchmarks even popular ones

We need to be doing evals on our evals

[Ichizoku @Ichizokuagents]

Anthropic の Claude Duetは、自律的に動くエージェントでありながら、ユーザーに代わって行動する前に確認を求める設計になっています。

業務にエージェントを導入するときに大切なのは、どこまで自動で進め、どこで人間が判断するのかを最初に決めておくことです。

確認ポイントを明確にしておくと、現場の安心感が高まり、結果として利用も定着しやすくなります。

[Claude @claudeai]

We’re opening a research preview of Claude Duet, a new app where Claude works as a proactive agent.

It comes to you with what needs your attention, completes tasks you ask of it, keeps working when you step away, and checks with you before it acts on your behalf.

[Ichizoku @Ichizokuagents]

エージェント開発で一番つまずくのは、プロンプトやツールを変えたときに「良くなったのか、悪くなったのか」が分からないことです。

CursorのAgent SDKは、プロンプトをMarkdown、ツールをTypeScriptで定義し、評価（evals）を最初から組み込める設計になっています。

変更のたびに同じ評価セットで測れる仕組みを用意しておくと、改善のスピードは大きく変わります。

まず評価の基準を決め、それから作り込む進め方がおすすめです。

[Cursor @cursor_ai]

The Agent SDK is now available.

Define agents as code, with prompts in Markdown and tools in TypeScript. Deploy them on our hosted infrastructure, or run them on your own.

Built-in evals let you measure every change and make your agents better over time.

[Ichizoku @Ichizokuagents]

Aaron Levie氏は、AIにも「ゼロトラスト」の時代が必要だと述べています。エージェントの行動とエージェントが扱うデータに対して、保護、監査、封じ込めの仕組みが求められるということです。

Ichizokuでは、すべてのエージェントを「システムへのアクセス権を持つ、新しく入った外部委託のスタッフ」のように扱っています。

・権限は必要最小限に絞る
・すべての操作をログに記録する
・業務責任者が実際に操作できる停止スイッチを用意する

ガバナンスの設計をパイロット導入後に先送りすること。

それこそが、企業のAIエージェント活用がパイロット段階で止まってしまう理由です。

[Aaron Levie @levie]

Good post to start thinking through the long term safety approaches to managing intelligence in an enterprise. As agents begin to do vastly more task execution in the organization than humans, our need to secure, govern, control, and audit that work will become paramount.

You’ll have agents operating against most of your most valuable data; they’ll be making decisions that will be harder and harder to reverse engineer; we’ll need to understand the liability and accountability regimes when models make decisions for us; and we need ways of containing the blast radius of accidentally or intentionally malicious agents.

“Treating frontier closed and open weight models like insider risks is a way to build such a system. Not because they are necessarily malicious, but because any sufficiently capable actor with access to important systems can make mistakes or be compromised, and the architecture of containment and control must account for that”

In a sense, AI will need to have its “zero trust” era that security saw. And all of this leads to needing various layers of protection and auditability of what agents are doing, what data they can work with, and controls for when things go wrong. And a huge opportunity right now for those building such systems across the enterprise.

[Ichizoku @Ichizokuagents]

＼AI-PAX 2026 大阪、明日から開催です／

Ichizokuのブース【2-14】でお待ちしています。

AIエージェントの設計・導入から、オブザーバビリティ、内製化支援まで。

「自社の場合どう進めるか」を、その場で具体的にご相談いただけます。

📅 10/29(木)–30(金)｜グランフロント大阪｜入場無料

▼来場登録・詳細
https://t.co/LzKgOecezm

#AIPAX #AIエージェント #生成AI

[Ichizoku @Ichizokuagents]

Hamel Husain氏とBen Hylak氏が、評価のためのシミュレーションについて話しています。

本番のトレースを再生し、エージェントの周りにあるデータやツールを再現して、実行ごとに回答、コスト、ツールの挙動を確認する。という内容です。

企業のプロジェクトで難しいのは、クライアントのシステムを再現する部分です。

Ichizokuでは、まずCRMやERPの応答と権限をサンドボックス内に作り直します。そのうえで、リリースのたびに実際に起きた失敗を再生して確認しています。

入力と出力だけを確認するテストでは、エージェントの失敗は見つかりません。再生することで、その失敗を捉えることができます。

[Hamel Husain @HamelHusain]

Recently had the chance to interview @benhylak on how he is thinking about simulations in our AI Evals Course 😁

Simulations are incredibly useful for evals when you do them well. Ben discusses what he learned from implementing simulations for evals at several companies. Some fun topics came up, my favorite being "simulation awareness" - when models know they are in a simulation.

Below is a chapter summary:

Why input/output tests miss agent failures
Replay production traces to see what a change breaks
Recreate the data and tools around the agent
How agents detect simulations and change their behavior
Choose scenarios that test the change you made
Check answers, costs, and tool behavior across runs
Replay known failures to verify a fix
Common mistakes that make simulations misleading
Check that the simulation reproduces production behavior
When to start using simulations

You can also watch this on YT: https://t.co/JOCncyIMH9

[Ichizoku @Ichizokuagents]

企業向けエージェントの開発をプロンプトから始めることはありません。

まず作るのは、例外の記録です。

最初の2週間は実際に業務を行うチームの隣で、標��の手順から外れたケースを��べて記録します。
誰が対応したのか、何を確認したのか、どれくらい時間がかかったのか。

この記録が、そのまま評価セットになり、エスカレーションのルールになり、エージェントが担う業務の範囲になります。

正常系は簡単な部分です。本番の成否を決めるのは、例外への対応です。

#AIエージェント #エンタープライズAI #AI導入