Technology Radar についてはここにまとめている。
この記事では次のことがわかる。
- 今号のテーマ
- 各カテゴリーごとの Adopt / Hold / ピックアップを紹介
- ピックアップは将来的に影響がありそうなものや面白そうなものを選んでいる
- 個人的な思いなども書いているので参考に
その他のまとめ
今号のテーマ
Infrastructure Orchestration Arrives for AI: インフラのオーケストレーションが必要に
AI モデルを扱う際に単一 GPU では足りなくなってきたので複数インスタンスでの構成が必須となってきているという話題。トレーニングだけでなく、蒸留なしでは動かすためにも GPU ひとつではキツいという状況らしい。
こういった状況へ対処するために k8s が用いられてきたが、最近は Uncloud や NVIDIA DCGM Exporter などの専用ツールが登場してきた。
The Rise of Agents Elevated by MCP: MCP 、そしてエージェントへ
各社が競って MCP を提供した結果、それを用いた高度なエージェントを構築可能となってきた。
エージェント構築のための知見やライブラリーなどが出揃ってきた影響も大きい。
マルチエージェントが当たり前となるだろうタイミングということもあり、アンチパターンの話題もある。
AI coding workflows: AI との開発
AI を用いた開発も一般化し、知見が蓄積されてきている。
- がっつり活用系
- サポートさせる系
よりうまく扱えるような周辺環境もととのってきている。
Emerging AI Antipatterns: AI アンチパターンの蓄積
AI を使うことが日常となってくると、アンチパターンもたくさん確認されるようになった。
シャドウ IT は日本だと少ない気もするが、興味があって個人で使う際にどこまでやっていいかの判断がつかないなどはあるだろう。 AI に生成させたコードを見て満足してしまうのとあわせると、判断が甘くなる可能性もある。
また、既存 API を MCP へ安直に変換したり、 SQL を生成させたりするのは明確にアンチパターンとされている。
個人的に気になったのは仕様駆動開発を採用した結果、仕様策定に時間をかけすぎたりビッグバンリリースになったりしているらしいということ。アジャイルソフトウェア開発宣言を声に出して読んできてほしい。仕様駆動開発で言っている「仕様」はわかっている範囲内での確定事項、くらいの認識で良い。ただ、要件や基本仕様など書いたことがない方はいきなり Kiro などの出力を見せられても噛み砕くのに時間がかかるのは当たり前。逆に時間をかけて理解に努め、自然言語でのシステム記述の勘所を養うのが良い。
Techniques
Adopt
Continuous compliance: 継続的セキュリティチェック
compliance と書かれているが、意味的にはセキュリティチェックのこと。
SLSA によるサプライチェーン攻撃や CI/CD パイプラインの乗っ取りなどを検出したり、 OSCAL によるセキュリティ担保の仕組みを記述しそれを OPA などでチェックしたりなど。
AI による生成が主流となる中、こういった仕組みでセキュリティを担保するほうが開発者も安心できる。
Curated shared instructions for software teams: プロジェクトでのプロンプト共有
npm script や各種タスクツールなどが提供するような、プロジェクト固有のタスク管理と同様、プロンプトも一緒に管理してしまおう、という発想。
CLAUD.md や copilot-instructions.md などツールごとのメモリー管理の仕組みや、 AGENTS.md などに書いておくのがひとつ。また、カスタムコマンドやサブエージェントを定義しておくことで、メンバーごとの結果のブレを抑えることができる。
Pre-commit hooks
Git は特定操作の前後に処理をフックする機能がある。
pre-commit フックは commit 直前に commit してよいかどうかを判定するためのシェルスクリプトだ。
AI が生成したコードがセキュリティ的に問題ないかをこれで確かめよう、という blip 。あまり重いものは開発のテンポが崩れるので、シークレットの検出くらいからはじめるのがいいだろう、と書いてある。
これについては昔記事を書いたことがあるので参照してほしい。 secretlint は軽量で、一瞬でチェックが終わるのでまず試してみると良い。
Using GenAI to understand legacy codebases: AI を用いたレガシーコードベースの理解
既存コードベースは 1 から読み込むより AI を用いて理解していくのがすでに鉄板となっている。 code agent に理解を促進するためのドキュメントを出力してもらったり、疑問点を聞くことであるていど解消できたりする。
- 企業内の情報は RAG などで即時に取り出し、課題把握やプロジェクトの立ち位置などがすぐに把握できる
-
プロジェクトに関わる全情報を集約して効率的な開発に役立てるツールもある
- が、これは全情報を握られるのでリスクが高いように思える
- メインフレームなどレガシーコードの解析は専用ツールが出ている
すでにコードベースの解析は前提であり、周辺コンテキストの取り込みによる精度向上や意思決定サポートにフォーカスが移っている。
また、オンボーディングが加速するという点については純粋なメリット。たぶん能力が高い人間ほど立ち上がりが速くなっている。だが、そもそも AI が取り込みやすいようプロジェクトに関する情報をテキスト形式で集約したり、社外に出して良い情報の選別が必要になったりと、実現には地道な作業が必要だ。
Hold
AI-accelerated shadow IT:
LLM というか ChatGPT などの動くコードを生成するエージェントが身近になったことで、管理者の知らないところでセキュリティインシデントが起きているかもよ、というもの。
最近は異なるツール間の接続に LLM によるデータ整形を用いるというのが出てきており、これは発見が難しいとのこと。 Slack につないだツール A の出力を見て、その出力をツール B に流し込みながら起動させるなどがわかりやすい例か。
最終的にどこまで情報を出すかの判断とそのオペレーションをどこまでできるかのハナシになるが、従来の ISMS などの組織的なハナシよりももっとミクロな、従業員単位での判断となる。いろいろ考えてみたが、オンボーディングや定期的な失敗談の共有などしか有効打がなさそう？
Capacity-driven development: リソース効率重視の開発
チームトポロジーで言うところのストリームアラインドチームなのに、稼働が空いているときに別プロジェクトの仕事を差し込まれるということが増えているそうな。 ThoughtWorks は全世界のお客さんが相手のようなので全世界でこういう傾向があるのだろう。原因は専門家ではないのでわからない。
日本ではチームのフロー効率 vs リソース効率の文脈で議論されている。初出は 2017 年。
This is Lean という本で紹介されている概念の紹介となっている。
どちらかというとリソース効率重視の文化が多かったが、こういった議論を端緒として意識されるようになり、フロー効率重視でいきますと宣言しているところも増えている印象。
Complacency with AI-generated code: 生成させたコードに満足しちゃう
たぶん、職業プログラマーとして書かせている方には当てはまらないという感覚がある blip 。少なくとも観測範囲の方でこの状態に陥っている方はいらっしゃらない。
ただし、エンジニアの労力の振り向け先が正しく作ることから AI をどう使うかにシフトしているという論文があるので、本質的な複雑性に割けるリソースが減っている可能性はある。
生成させた際によくある、コピペコードやその場限りのコードについては内部品質指標を最初から指示しておくというのが良いかもと思ったが、最初から正解は出てこない。レビューまでを自動化することであるていどなんとかなるが、 1 回のイテレーションが長くて実用に耐えない。
で、このポストの方法は今動かない。 code agent の変更に追従するコストも高いので、ここらへんを都度変更、チューニングしていくのも難しい。いや、できるが、今後このへんを全部 agent がやってくれる未来がくるとして、専門性を高める時間を厚めにしたほうが生存戦略として筋が良いのではないか？と思い頑張ってレビューしていくという手法に落ち着いた。
レビューの方向性として 2 つ。
- 自分の学習のためのレビュー
- 出てきたもののうち、わからないところを質問攻めにする
- 甘いところのスルー / 修正判断
- 今はこれでええか、忘れないようにタスク積んでおこう vs これはないでしょというツッコミ
- あとあと大規模な書き換えが必要でも、今現在は必要最小限で進めていける
- もちろんあとあと詰むコードかどうかを見分けるために経験は必要
個人的な時間の使い方として前者が 80% 。
なお、そもそも方向性の違うものが出てきたときは CLAUDE.md などコンテキスト注入のための仕組みに対してズレてる部分を逐一入れ込んでいく。毎 PR でこのへんの変更が入るのは普通という感覚になってきた。
Naive API-to-MCP conversion: API から MCP への安直な変換
API は既存システム、主に人間向けに設計されているので、 API の設計をそのまま MCP に適用しても文脈や特性が違う LLM 相手にはうまくいかないよ、ということらしい。
Standalone data engineering teams: 独立したデータエンジニアチーム
データは課題や実世界と紐づいていなければ有効に使うことはできないので、データエンジニアリングだけやるチームは意味がないよ、というもの。プラットフォームチーム / イネイブリングチームどちらであってもよくない、ストリームアラインドチームでデータを分析しながら価値を作っていこう、という主張のようだ。
というのも、 AI の処理能力が高まった結果、ドメインの深いデータでなければ価値を生み出すのが難しいから、ということらしい。
Text to SQL: AI に SQL 書いてもらう
SQL を AI に書かせるのは精度が悪いということらしい。そもそも SQL はかなりドメインに食い込んだ操作なので、それはそうだ、という感想でしかない。 ORM の操作ですらおぼついてない印象がある。
ピックアップ
AGENTS.md - Trial
LLM に渡すコンテキストを管理するファイル。主に coding agent 相手に使われる。
一般的なフォーマットです、という形で紹介されているが、 Anthropic はのってきてない。 OpenAI が主導して作ったものらしい。
個人的にファイルひとつで注入というより MCP で統一的に扱えるようになったほうがいいんじゃないのという感じはする。
TCR (Test && Commit || Revert) - Trial
テストがすべて通ったら git commit 、失敗したものがあれば git revert を機械的にするという開発手法のこと。
頑張って機能実装したとしても typo でテストが落ちたらすべてなかったことになる。
Kent Beck 氏は学習スタイルのひとつとしてならやってもいいかもね、という態度のようだ。細かく刻むことを強制するので、作業順序を考えたり、漸次的に改善を積み重ねていく経験は積めるだろう。
GraphQL as data access pattern for LLMs: LLM への GraphQL 解放 - Assess
GraphQL はもともと変更が多いクライアント向けに動的にクエリーを組み立てることで無駄なデータの取得 / 複数 API の呼び出しを防ぐというもの。それを LLM に対しても適用しようという blip だ。ユーザーの要請は毎回変わるので、 LLM はそれに応えるため都度必要なデータのみを取得できる。
GraphQL サーバーは RESTful API を呼び出し、キャッシュしながら柔軟にデータを返す、という構成が割と効果的だ。そのため、既存で RESTful な API を組んでいれば MCP に転用しやすい。
LLM as a judge: LLM で判定する - Assess
Trial から Assess に落ちた。理由としては妥当性の低さと理由の不透明さ、そしてモデルの「好み」らしい。
モデルの「好み」について、ある LLM モデル A に生成させたものを LLM as a judge で評価したいとする。このとき評価に使うモデルが A そのもの / 系列 / 子孫関係にあたるものの場合、スコアが上昇するというものらしい。学習データが似かよれば同じ挙動を示すのはまあわかる。
代替として、まったく出自の違う安めのモデルを複数使って多数決もしくは加重平均するのが良いという報告がある。
ある程度以上の年代の方には MAGI システムといえば一言で伝わるか。軽く SF の世界になってきている。
Platforms
Adopt
Arm in the cloud: IaaS での ARM インスタンス使用
主要 IaaS ベンダーで ARM インスタンスが安定して使えるようになり、コストを下げるのに役立っているらしい。
Hold
なし。
ピックアップ
Dovetail - Trial
ユーザー調査の結果得られたデータを一元管理してインサイトを得るためのツール。
OpenFeature - Assess
フィーチャーフラグを実装するためのライブラリー。フィーチャーフラグについては次の記事が詳しい。
昔はフィーチャーフラグを使うな、という風潮だったが、今は割と使っている企業もあるらしい。ただ、記事を見てもらえばわかるが、コードの複雑性増加やテストの組み合わせ爆発に対しての対策がフィーチャーフラグの短期化くらいしかなく、導入には企業体力と覚悟が必要。
Tools
Adopt
すべて今では鉄板となってきたツール。
ClickHouse
オープンソースの OLAP データベース。分析用にも良いが OpenTelemetry やクラッシュレポートのデータを集積して置く場所としても良いらしい。
NeMo Guardrails
LLM アプリにガードレールを追加するライブラリー。望ましくない出力や話題展開を抑えたり会話の流れを制御できる。
pnpm
パフォーマンスが良く、昨今のサプライチェーン攻撃に対する防御策も講じてあるため現在のところこれ 1 択というツール。
Pydantic
型アノテーションツール。
Hold
なし。
ピックアップ
AI を用いた開発を加速ツールをピックアップしてみた。
AI Design Reviewer - Trial
AI を用いてビジュアルデザインをレビューしてくれる Figma プラグイン。レビュー観点を広げるという意味合いで一度使ってみると良いだろう。
Context7 - Trial
実際に使っているライブラリーやツールのバージョンに応じたサンプルコードを生成し、 LLM の手本としてコンテキストを注入できるツール。メジャーバージョンが変わった直後のライブラリーを使う場合などに効果を発揮しそう。
UX Pilot - Trial
テキストや画像を入力として渡すとビジュアルデザインや画面遷移を作成してくれるツール。 Figma に書き出せるプラグインもあるらしい。
Vercel v0 と同様、初期の探索や学習に使うのが良いだろう。
Augment Code - Assess
コードベース全体に対するインデックスを LLM に提供したり、 Slack 経由でクエリーしたりできるようにするツール。 Serena のエンタープライズレベルのようなものらしい。
Docling
PDF や PowerPoint などからテキストを抽出するオープンソースのツール。 OCR を使うため、段組みなどにも対応できるらしい。
E2B
AI に生成させたコードをサンドボックス内で実行するためのツール。
oRPC
OpenAPI をメインに据えたサーバー実装用ライブラリー。
SweetPad
Xcode でなくても Swift を用いた iOS 開発ができるようになる拡張。
Languages & Frameworks
Adopt
Fastify
デファクトスタンダードになってきている。 Express の後継。
LangGraph
マルチエージェントアプリを作るためのフレームワーク。グラフ構造をベースにしつつもメモリーなど低レベルの管理も可能で、鉄板となっている模様。
vLLM
自前で LLM モデルをホストできるツール。自前でインフラをセットアップする以外にもクラウド上で使えるみたいなので、外に出せない情報を LLM に処理させたい場合などで有用だろう。
Hold
なし。
ピックアップ
Tauri - Trial
Web アプリをデスクトップアプリケーションとしてラップするツール。 Rust で書かれている。
Agno - Assess
マルチエージェントを構築するためのフレームワーク。 FastAPI ベースらしい。
assistant-ui - Assess
チャット UI を作るためのライブラリー。最近のトレンドにのって、細かい部品を提供している。
LMCache - Assess
LLM の入出力に対して key-value 型のキャッシュを提供するツール。 vLLM と組み合わせて使うと良い。
Mem0 - Assess
エージェントの記憶管理ツール。短期記憶、長期記憶など人間の認知プロセスを真似て設計されているようだ。
特に長期記憶は一貫した受け答えに寄与している模様。
Discussion