Technology Radar についてはここにまとめている。
この記事では次のことがわかる。
- 今号のテーマ
- 各カテゴリーごとの Adopt / Hold / ピックアップを紹介
- ピックアップは将来的に影響がありそうなものや面白そうなものを選んでいる
- 個人的な思いなども書いているので参考に
その他のまとめ
今号のテーマ
Adopt 入りの理由が弱いものや ThoughtWorks 社の嗜好が入っているものが多い印象を受けた号。あくまで参考情報として参照するとよいだろう。
Supervised agents in coding assistants: コーディングアシスタントにおける指示駆動型エージェント
Cursor や Cline など IDE に組み込まれたエージェントが良さそう、というテーマ。人間が都度、口を差し挟めるというのが使いやすくて良いというニュアンスが書かれている。
同時に注意点も書かれているが、人間がすべてわかったうえで指示を出してやる必要がある。すべてエージェントが組んでくれるが、できたものを使うかどうかは使用者の責任だ。実用的なものほど対象領域の知識、アーキテクチャー、コード、ファイルパーミッション、 IoC 設定など広範な知識が求められる。原文の最後の <q>With great power…</q> というのはスパイダーマンで出てくるセリフで、全文は次だ。
With great power comes great responsibility.
エージェントが求めてくる許可についても同様だがいまのやり方は許可を出す側も疲れる。 Deno のように実行時に許可する権限を指定する、ガードレールのようなものでエージェントが操作できる範囲をあらかじめ決めておくなど、補助的な仕組みは早晩揃うだろう。
なお Devin などコーディングアシスタントではなく、独立したプロセスとしてコード生成するのはムダが多いと感じている。 PR 段階で指摘をいれるのは品質の作り込みや教育における情報伝達においてロスが大きすぎる。より早い段階、コードを書く時点で密にやりとりするほうがリソースの使い方として有用だろう。
これからの課題は使いこなせるレベルに達するまでのロードマップ策定や知識 / スキルのトランスファーなど、いわゆる教育だろうか。こればっかりは人間 2 人とエージェント 1 人でのプログラミングなどで地道にやっていくしかない気がしている。良いプラクティスは出てくるだろうが基本路線は変わらない可能性も高い。
Evolving observability: 進化する可観測性
OpenTelemetry の普及によってツール選択の自由が獲得されたこと、 LLM など大容量のコンテキストを飲み込めるツールによって分析が捗ることのふたつが挙げられている。
LLM による複雑なデータの分析は相性が良いらしく、今号では折に触れて似たような事例が報告されている。
R in RAG: RAG の Retrieval 処理
RAG: Retrieval-Augumented Generation の Retrieval 部分、つまり回答文生成の元データとなる部分の取得についてかなり進展があるとのこと。具体的なものとして次が挙げられている。
- corrective RAG
- Fusion-RAG
- Self-RAG
- FastGraphRAG
Taming the data frontier: データの未開領域を使いこなす
非構造化データなど読み解くのが難しかったデータを LLM によって扱いやすくなってきている。
より目的に叶う形でのデータ活用がしやすくなったということが書かれている。
Techniques
Adopt
Data product thinking: データを製品として考える
顧客の目的に合致するようにそのデータの提供や分析の方法をともに模索する考え方のことを言うらしい。
データを必要とする人間がデータを揃える、となると現実的でないこともあるためこの考え方が Adopt として紹介される時代になったのは良いことだろう。ただ、データの源泉を考えると意味のある活動をしている主体に、さらにこういったコストを上乗せする場面も多くなる気がするので、やり方の共有やツールによる補助などが進展するとうれしい blip 。
Fuzz testing: ファズテスト
動くものに対してツールで無効なデータを入力していき、クリティカルな状態にならないかやメモリーリークを起こさないかなどを確認していく手法のことらしい。
生成 AI によってコードを生成する機会が多くなったことで相対的に重要性が上がっていると記載されている。のだが、品質の作り込みとは逆の方向性なのでメンタルモデルの変更は必須だろう。富豪的にそれっぽいものを生成したあとで、クリティカルな状態が発生しないことを確認していく。
Software Bill of Materials: SBOM
SBOM はサプライチェーン攻撃の台頭によって、依存ライブラリーに対してより自覚的になろうという意図で普及してきたものだ。
最近では使用する生成 AI の依存についても把握した方が良いとのことで、また違った観点で注目されている。
Threat modeling: 脅威モデリング
システムを取り巻く脅威についてあらかじめ議論し、想定されるリスクについての共有とクリティカルなものへの対処をすることらしい。
医療システムについてはリスク分析という形であらかじめやったりもするのだが、既存のシステムではコスパが悪い。やはりコードが生成されるものへとシフトしたことによってこういった手法に新たに焦点が当てられようになったという経緯なのだろう。
Hold
AI-accelerated shadow IT: AI が加速する シャドー IT
生成 AI によってシャドー IT 増加の可能性が上がるが、きちんと把握していきましょう、という blip 。
個人的には中央集約的に管理は難しい時代になってきているので、セキュリティや法令遵守などについては最低ラインを担保しつつ、各チームレベルでうまくやってくださいね、という方向性が良いのではと考えている。
Complacency with AI-generated code: 生成されたコードへの過信
vibe coding などで当初の目的を果たす時間が非常に少なくなっているが、鵜呑みにするのは危ないよ、という blip 。
生成 AI を使いはじめると、クリティカルシンキングの対象が自分自身の思考やドメイン知識など前提データなどから、生成 AI の応答全般にすり替わり、クリティカルシンキングの数自体も減るらしい。
事例を収集して分析した結果らしいので、物珍しさやお手並み拝見という意識でこういった結果になっているのではないかとも受け取れる。
Cursor でコード生成させたらそれっぽいものを出力してくるものの、目的の深い理解をする前に生成しはじめたりメンテナンスに難のある結果になったりしたので、そこに目がいってしまいがちと感じた。経験が少ないエンジニアだと、出力量に圧倒されて当初の目的を果たせているかという観点がおざなりになってしまう可能性もある。
個人的に生成 AI は細かくタスクを分解した後に使うのが生成結果の確認も含めて楽な気がする。そうすると目的に対する戦略も練りやすいし、他の選択肢の検討やコードへの納得感、妥当なコードだという感覚も醸成されやすい。
本番投入は待て、と書いてあるが妥当だろう。
Local coding assistants: スタンドアロン型コーディングアシスタント
コーディングアシスタントは強力だが、秘密保持など企業の競争力向上やコンプライアンス準拠に関しては手放しで使えるものではない。こういった制約を満たしながらコーディングアシスタントを使いたいとなると、手元のマシンで動くモデルを使うしかない。しかし使い物になるモデルはクラスターで動かすような大仰なものとなるし、各社ともクラウドベースでの提供がメインなので現在はまだ様子見だ、という blip 。
DeepSeek などそれなりに手元で動くモデルも出てきたが、ここで問題になっているのはセキュリティなのでそれをクリアするのはしばらくかかるだろうという意味合いで Hold に位置していると思われる。
次巻 Volume 33 は半年後だが、そこで、もしくはそれよりも早く状況が変わうる blip だ。
Replacing pair programming with AI: ペアプログラミングの代わりに AI を使う
ペアプロによって何を得ていたかによるが、単純にペアプロというプロセスを AI との共同作業には置換できない、という blip 。
But they don't help with any of the team collaboration benefits, like keeping the work-in-progress low, reducing handoffs and relearning, making continuous integration possible or improving collective code ownership.
日本語訳すると、次についてはペアプロによってもたらされるものだと書いてある。
- WIP 制限の遵守
- 引き継ぎと開発文化や歴史の再学習の低減
- 継続的インテグレーションプラクティスの実践
- コードが共同所有物であるという意識
ペアプロだけでなく、モブプロでも得られるものなので、気になった方は次の本を読んでみると良い。
Reverse ETL
データを中央集約して処理したあと、再度プロダクト側に戻す、というものらしい。中央集約すると処理時間が増えたり、必要なデータをリアルタイムで取得できなかったりと現場ニーズに合わないという課題が新たに出てきているとのこと。
代わりにデータメッシュを推し進めて、必要なときに必要なデータを使っていくという方向で考えると良いと書かれているが、組織規模が小さいとデータメッシュを志向するのは難しい。
この blip ではマーケティングとしての reverse ETL に気をつけなさい、ということも書かれており、こちらが本音のようにも読める。
SAFe™
Scaled Agile Framework の略。アジャイルではない。
ピックアップ
Architecture advice process - Trial
ARB 、 Architecture Review Board: アーキテクチャー承認委員会では、プロダクトのアーキテクチャーについてレビュー、承認するらしい。が、これの悪影響が大きいということで代替のように出てきた blip 。
プロダクトを実際に使う人間や専門家などにアドバイスを求めた上であれば、プロダクトを作る人間がアーキテクチャーの決定権を持つ、というやり方らしい。
Lean と DevOps の科学でも、チームがやりやすい方法でやるのが一番良いという話題があったので、整合性が取れている。
Prompt engineering: プロンプトエンジニアリング - Trial
reasoning model 、推論モデルが出てきたことで従来ハックの対象だったプロンプトがそうでなくなってきている、という blip 。
必要な情報を与えれば CoT: Chain of Thought をあるていど自前でやってくれるようになった。このため few-shot prompting などでは望む結果が得られにくくなったり、推論に時間がかかるようになっている。
reasoning model を使う場合は、シンプルに初期設定とほしい答え、必要であれば文脈を伝える、という形で望む回答が得られるだろう。
AI-friendly code design: AI が扱いやすいコード - Assess
人間にとって理解しやすいコードは AI も理解しやすい、という blip 。
ここでいう理解しやすさは読みやすさとは比例しない。
適切な命名をする、ドメインモデルに基づいて表現力豊かにコードを書く、などが良いとされる。
AI-powered UI testing: AI を用いた UI テスト - Assess
マルチモーダル AI が人間と同じ感覚で UI を理解してくれるなら、壊れやすい E2E テストを代替できる可能性がある。これはその可能性についての blip だ。
サービスとして提供されているものもあり、自然言語でオペレーションを書けるらしい。
Platforms
Adopt
GitLab CI/CD
GitLab が提供する CI/CD 機能が良いとのこと。
特に CI の DAST がすごく、簡易的なペネトレーションテストが実行できるらしい。
Trino
複数データソースをまたいで SQL で分析できる分散型の OSS らしい。もともと Presto という名前で開発されていた。
Amazon Athena でも使われているらしい。
マネージドサービスは StarBurst という名前で提供されている。
Hold
Tyk hybrid API management
マルチクラウドやオンプレクラウド混在で API を提供するときに使える管理サービスらしい。
本番投入するのはやめとけという感じのことが書かれている。
ピックアップ
Model Context Protocol (MCP) - Assess
Web 検索も LLM 経由で扱えるようになってきたとはいえ、より役に立つデータを扱いたいということで策定されたプロトコル。
既存のネットワーク技術を前提として策定されているので対応も簡単、如実に LLM が拡張されているのがわかるのでうれしい、ということでいま巷を騒がせている blip だ。
OpenAI も準拠することを決めた。
対して Google は Agent2Agent Protocol を出してきた。
MCP でエージェントの役割規定や扱うデータの質向上を、 A2A でエージェント間で議論させることで、良い結果が得られるという棲み分けのようだ。
想定通りの方向性での拡張だが、ネットワーク経由ということで立ち上がってくる問題としてセキュリティや倫理などがある。ただ、いずれ落ち着くところに落ち着く可能性が高い。
今はどういったデータをお客さんが必要としているのかや Data product thinking を適用しながらどうまとめるかに頭を悩ませるのが良いだろう。
Reasoning models: 推論モデル - Assess
推論モデルはベンチマーク結果だけでなく、実際に使ってみると秘書のように仕事をこなし、議論もできる。
トレーニング方法を調べてみたのだが、 LLM に対し幼児期から小学校低学年レベルの教育を施すようなイメージが近い。なので、常識の範囲で議論ができるし、的確に意図を汲んで仕事してくれる。
ただ、一部文化圏では違和感がある教師データをトレーニングに使っている可能性もあるため、ズレが出たり論理が飛躍しているように感じることもあるだろう。日本語や日本文化における教師データでトレーニングできれば、より自然になる可能性があるだろう。
reasoning model の登場によって Prompt engineering のやり方も変わってきているので、改めて学び直すのもよいだろう。
Tools
Adopt
Renovate
dependabot より使い勝手の良い依存パッケージ更新サービス。依存パッケージのメンテナンスを省力化したい場合はまず見てみるとよいだろう。
自動マージについても、 AI-powered UI testing などで E2E のメンテナンスコストが下がってきているので取り入れやすくなってきている。
uv
Rust 製 Python パッケージ管理ツール。とにかく速いのでそれだけで Adopt 入りしたらしい。
Vite
Webpack の代替としての地位が揺るがなくなってきた。フレームワーク使っていれば、いつの間にかお世話になっているという状況だ。
ただ、 Rspack という選択肢もあるので好みで選択すると良い。
Hold
なし。
ピックアップ
Claude Sonnet - Trial
reasoning model の性能の高さを示した印象が強いモデル。 Cursor や Cline の裏側で使ったりなど、実用性が高い。
Cursor - Trial
AI エージェント搭載の IDE としては最古参？
使い勝手が良いので、 AI エージェントと協働するとはどういうことかを試したい場合はまず使ってみると良い。
D2 - Trial
テキストで図を書けるツール。文法は独自のものみたいだが、 mermaid よりも自由度の高い図が描けそう。
Playground があり、 IDE extension も幅広く用意されてるようなので使い勝手も良さそうだ。
Languages & Frameworks
Adopt
OpenTelemetry
デファクトスタンダードになりつつあるとのこと。 OTLP の存在が大きい。
React Hook Form
React で入力まわりを扱う際によく使われているパッケージ。
型まわりが甘いため、コードが冗長になってしまうこともあり、万人におすすめというわけではないが代替が存在しない。
Hold
Node overload: Node.js 濫用
他の処理系に比べ、計算量が多い処理に向いていないと言われる Node.js だが、検討せずに選択されることが多いという指摘をしている blip 。
ThoughtWorks 社ではチームのスキルセットの現状に依らず、最適なものを使うと良いというスタンスのようだ。
ピックアップ
MarkItDown - Trial
様々な形式のファイルを Markdown 形式に変換できるライブラリー。
MCP が出てきたとはいえ、 LLM への入力としてテキストが求められる機会も多いため、こういったツールの出番は多いだろう。
Presidio
データを匿名化するライブラリー。ログに流すものをマスクするにはちょっとサイズが大きいので投入できるプロダクトは限られそうだが、大量のデータを匿名化して LLM に入力するなどで使えるのでは。
Discussion