Technology Radar 2025年4月版(Vol. 32)を読む
Technology RadarのApr. 2025が出ていたので、気になったブリップについてまとめる。
コーディングアシスタントを中心にLLM関連のブリップが多かった。驚いたのは、SAFe（Scaled Agile Framework）がバリューストリームを阻害するって判断になって保留（Hold）に移動している事だった。
読んでみて、やっておきたいことを以下に挙げておく。
- アーキテクチャアドバイスプロセスを読む
- S3LLMの論文を読んで、触ってみる
- (SHOULD) GraphRAGについて調べてみる
- ABsmartlyを触ってみる。Unleashとの使い分けなんかの考察ができれば。
- (SHOULD) Graphanaのエコシステムについて調べて、どの程度できることがあるのかを把握する
- (SHOULD) Supabaseを触ってみる
- RAGで使えそうなPostgreSQL拡張を調査する
- ライブラリ等のパッケージの最新版を返すMCPサーバを作ってみる。
- Tupleを使ってみる
- OpenRouterを使えるコーディングエージェントを調べて、契約してみる。Cursor、Clineは使える。Claudeは使えなさそう。
- Windsurfを触ってみる。
- OpenTelemetoryの本を読む
- MarkItDownを触ってみる
- Browser Useを触ってみる
その他の気になったブリップとその感想を以下にまとめる。
テクニック
採用（Adopt）
2. ファズテスト
ファズテスト、または単にファジングとは、古くからあるテスト手法ですが、いまだあまり知られていない手法の一つです 。その目的は、ソフトウェアシステムにあらゆる種類の無効な入力を与え、その動作を観察することです 。例えば、HTTPエンドポイントの場合、不正なリクエストは4xxエラーになるべきですが、ファズテストでは5xxエラー、あるいはそれ以上の問題を引き起こすことがよくあります 。十分に文書化され、ツールによってサポートされているファズテストは、AI生成コードの増加やAI生成コードに対する自己満足が進む現在、これまで以上に重要です 。つまり、コードの堅牢性と安全性を確保するために、今こそファズテストを採用すべき時期です 。
試用（Trial）
5. APIリクエストコレクションをAPIプロダクトアーティファクトとして扱う
APIを製品として扱うことは、開発者体験を優先することを意味します。これは、API自体に賢明で標準的な設計を組み込むだけでなく、包括的なドキュメントとスムーズなオンボーディング体験を提供することによっても実現されます 。OpenAPI（Swagger）仕様はAPIインターフェースを効果的に文書化できますが、オンボーディングは依然として課題です 。開発者は、事前に設定された認証と現実的なテストデータを含む、動作する例に迅速にアクセスする必要があります 。APIクライアントツール（Postman、Bruno、Insomniaなど）の成熟に伴い、APIリクエストコレクションをAPIプロダクトアーティファクトとして扱うことを推奨します 。APIリクエストコレクションは、開発者が最小限の労力でAPIのドメイン言語と機能を理解できるよう、主要なワークフローを通じて開発者をガイドするように慎重に設計する必要があります 。コレクションを最新の状態に保つために、リポジトリに保存し、APIのリリースパイプラインに統合することをお勧めします 。
感想: 確かにオンボーディンは課題であることを実感している。APIリクエストコレクションって何だろう。
6. アーキテクチャアドバイスプロセス
大規模なソフトウェアチームにおける長年の課題の1つは、システムの進化を形作るアーキテクチャ上の決定を誰が行うかを決定することです 。State of DevOpsレポートは、従来のアーキテクチャレビューボードのアプローチが逆効果であり、しばしばワークフローを妨げ、組織のパフォーマンス低下と相関していることを明らかにしています 。魅力的な代替手段は、アーキテクチャアドバイスプロセスです。これは分散型アプローチであり、影響を受ける人々や関連する専門知識を持つ人々からアドバイスを求める限り、誰でもアーキテクチャ上の決定を下すことができます 。この方法は、小規模および大規模の両方でアーキテクチャ品質を損なうことなく、チームがフローを最適化することを可能にします 。一見すると、このアプローチは議論を呼ぶように思えるかもしれませんが、アーキテクチャ決定記録や諮問フォーラムなどの実践は、決定が情報に基づいたままであることを保証しつつ、作業に最も近い人々に意思決定権を与えます 。私たちは、このモデルが高度に規制された産業を含む、ますます多くの組織で大規模に成功するのを見てきました 。
感想: アーキテクチャアドバイスプロセスとは何だろう？ ADRをいちいち書くのは面倒だ。MiroやJIRAに書いて終わりにしたい。ZoomのMTGの録音データから上手くLLMで生成できないのだろうか？
7. GraphRAG
前回のRAGの更新で、Microsoftの論文で当初2段階のアプローチとして記述されていたGraphRAGを紹介しました。(1) ドキュメントをチャンクに分割し、LLMベースのチャンク分析を使用してナレッジグラフを作成する 。 (2) クエリ時に埋め込みを介して関連するチャンクを検索し、ナレッジグラフのエッジをたどって追加の関連チャンクを発見し、それらを拡張されたプロンプトに追加する 。多くの場合、このアプローチはLLM生成応答を強化します 。私たちは、構造情報（抽象構文木や依存関係など）を使用してナレッジグラフを構築する際に、GenAIを使用してレガシーコードベースを理解する場合にも同様の利点を観察しました 。GraphRAGパターンは、Neo4jのGraphRAG Pythonパッケージなどのツールやフレームワークが登場し、そのサポートが強化されています 。また、GraphitiもGraphRAGのより広範な解釈パターンに適合すると考えています 。
感想: 昔からNamazuやHyperEstraierやApache Solrをイジって遊ぶのが好きだったので、この辺で手を出してみるのもいいかも。
10. プロンプトエンジニアリング
プロンプトエンジニアリングとは、高品質でコンテキストに応じた応答を生成するために、生成AIモデルのプロンプトを設計および改良するプロセスを指します 。これには、モデルの出力を最適化するために、タスクやアプリケーションに合わせて明確で具体的かつ関連性のあるプロンプトを作成することが含まれます 。LLMの機能が進化するにつれて、特に推論モデルの出現により、プロンプトエンジニアリングの実践も適応する必要があります 。AIコード生成の経験に基づいて、推論モデルを使用する場合、数ショットプロンプトが単純なゼロショットプロンプトよりもパフォーマンスが低い場合があることを観察しました 。さらに、広く使用されている思考連鎖（CoT）プロンプトは、推論モデルのパフォーマンスを低下させる可能性があります。これはおそらく、強化学習によってCoTメカニズムがすでに組み込まれているためです 。私たちの実体験は、学術研究と一致しており、「高度なモデルはソフトウェアエンジニアリングにおけるプロンプトエンジニアリングの必要性を排除する可能性がある」ことを示唆しています 。しかし、推論モデルと汎用LLMの間で応答時間とトークンコストに違いがあることを考慮すると、ハルシネーションを減らし、出力品質を向上させる上で、従来のプロンプトエンジニアリング技術は依然として重要な役割を果たします 。エージェント型アプリケーションを構築する際には、ニーズに基づいてモデルを戦略的に選択し、対応するプロンプトテンプレートと手法を継続的に改良することをお勧めします 。パフォーマンス、応答時間、トークンコストの適切なバランスを取ることが、LLMの有効性を最大化する鍵となります 。
感想: 「推論モデルを使用する場合、数ショットプロンプトが単純なゼロショットプロンプトよりもパフォーマンスが低い場合があることを観察しました 。さらに、広く使用されている思考連鎖（CoT）プロンプトは、推論モデルのパフォーマンスを低下させる可能性があります。」ときたか。一生懸命、fewショットだの、CoTだのを調べたのに…
12. GenAIを用いたレガシーコードベースの理解
過去数ヶ月で、GenAIを用いたレガシーコードベースの理解は実際に進歩を遂げました 。GitHub Copilotのような主流のツールは、レガシーコードベースの近代化に役立つと宣伝されています 。SourcegraphのCodyのようなツールは、開発者がコードベース全体をナビゲートし、理解することを容易にしています 。これらのツールは、多様なGenAI技術を使用してコンテキストに応じたヘルプを提供し、複雑なレガシーシステムでの作業を簡素化します 。それに加えて、S3LLMのような専門フレームワークは、LLMがFortranやPascalで書かれたような大規模な科学ソフトウェアをどのように処理できるかを示しており、従来のエンタープライズIT以外のコードベースにもGenAIによる理解をもたらしています 。世界中の膨大な量のレガシーソフトウェアを考えると、この技術は今後も牽引力を増していくと私たちは考えています 。
感想: Codyは触ってみた方法がいいかなあ。S3LLMの論文もLLMを使って読んでみるのもいい経験になるかも。
評価（Assess）
14. AIパワードUIテスト
AIによるソフトウェアチーム支援の新しいテクニックが、コード生成を超えて登場しています 。注目を集めている分野の一つは、LLMのGUI解釈能力を活用したAIパワードUIテストです 。これにはいくつかの手法があります。あるカテゴリのツールは、UIスナップショット処理用に微調整されたマルチモーダルLLMを使用し、自然言語で書かれたテストスクリプトでアプリケーションをナビゲートできるようにします 。この分野の例には、QA.techやLambdaTestsのKaneAIがあります 。別の手法は、Browser Useに見られるように、マルチモーダル基盤モデルとPlaywrightのウェブページの構造に関する洞察を組み合わせるもので、微調整されたモデルに依存しません 。AIパワードUIテストをテスト戦略に統合する際には、それらが最も価値を提供する場所を考慮することが重要です 。これらの方法は手動の探索的テストを補完することができ、LLMの非決定性が不安定さを引き起こす可能性はありますが、その曖昧さは利点となることもあります 。これは、セレクターが欠落しているレガシーアプリケーションや、ラベルやクリックパスが頻繁に変更されるアプリケーションのテストに役立つ可能性があります 。
感想: この手のテストツールは、mablとかの既存サービス事業者の地位を脅かしそう。
16. LLMからの構造化出力
LLMからの構造化出力とは、言語モデルの応答を定義されたスキーマに制約する実践を指します 。これは、汎用モデルに特定の形式で応答するように指示するか、モデルを微調整して、例えばJSONを「ネイティブに」出力させることで達成できます 。OpenAIは現在、構造化出力をサポートしており、開発者がJSONスキーマ、pydantic、またはZodオブジェクトを提供してモデル応答を制約できるようにしています 。この機能は、関数呼び出し、APIインタラクション、および外部統合を可能にする上で特に価値があり、正確性と形式への遵守が重要です 。構造化出力は、LLMがコードと連携する方法を強化するだけでなく、チャートのレンダリングのためのマークアップ生成のような幅広いユースケースもサポートします 。さらに、構造化出力は、モデル出力におけるハルシネーションの可能性を低減することが示されています 。
感想: ハルシネーションを低減できるなら使っていきたいな。LLMって自然言語を扱うものなのに、いつの間にか人工言語をメインで扱うようになってしまうのか？ また、XMLみたいな自己記述型のデータ構造の重要性が強調されるのだろうか。
保留（Hold）
17. AIによるシャドウITの加速
AIは、IT部門が要件に対応するのを待つのではなく、非コーダーが自分自身でソフトウェアを構築・統合するための障壁を低くしています 。この可能性に興奮を覚える一方で、AIによって加速されたシャドウITの最初の兆候についても警戒しています 。ノーコードのワークフロー自動化プラットフォームは現在、AI API統合（OpenAIやAnthropicなど）をサポートしており、AIをダクトテープのように使用し、以前は不可能だった統合（あるシステムでのチャットメッセージをAI経由でERP API呼び出しに変換するなど）を繋ぎ合わせることが魅力的になっています 。同時に、AIコーディングアシスタントはますますエージェント的になり、基本的なトレーニングを受けた非コーダーが内部ユーティリティアプリケーションを構築できるようになっています 。これらすべては、一部の企業で依然として重要なプロセスを支えているスプレッドシートの次の進化の兆候をすべて備えていますが、その影響ははるかに大きいです 。放置すると、この新しいシャドウITは、管理されていない、潜在的に安全でないアプリケーションの拡散につながり、データをますます多くのシステムに分散させる可能性があります 。組織はこれらのリスクを認識し、迅速な問題解決と長期的な安定性の間のトレードオフを慎重に検討する必要があります 。
感想: Excelレガシーみたいに、LLMレガシーが発生するのかも。
18. AI生成コードに対する自己満足
AIコーディングアシスタントが普及するにつれて、AI生成コードに対する自己満足に関する懸念を示すデータと研究が増加しています 。GitClearの最新のコード品質研究によると、2024年には重複コードとコードチャーンが予測以上に増加し、コミット履歴におけるリファクタリング活動が減少しています 。AIに対する自己満足を反映して、Microsoftの知識労働者に関する研究では、AIによる自信が批判的思考を犠牲にすることが多いというパターンが発見され、これはコーディングアシスタントの長期使用によって自己満足が定着するにつれて私たちが観察してきたパターンです 。教師付きソフトウェアエンジニアリングエージェントの台頭は、AIがより大規模な変更セットを生成するにつれて、開発者が結果のレビューにおいてより大きな課題に直面するため、リスクをさらに増幅させます 。「バイブコーディング」（開発者が最小限のレビューでAIにコードを生成させること）の出現は、AI生成出力に対する信頼が高まっていることを示しています 。このアプローチは、プロトタイプやその他の使い捨てコードの種類には適切である可能性がありますが、本番コードでの使用は強く警告します 。
感想: バイブコーディングの紹介でページビューを稼いでいるインフルエンサーはあとで信用を失うから注意を。「まだコーディングで消耗しているの？」系の記事には要注意。
19. ローカルコーディングアシスタント
組織は、特にコードの機密性に関する懸念から、サードパーティのAIコーディングアシスタントに警戒心を抱いています 。その結果、多くの開発者は、コードを外部サーバーに送信する必要をなくす、マシン上で完全に動作するローカルコーディングアシスタントの使用を検討しています 。しかし、ローカルアシスタントは、より大規模で高性能なモデルに依存するクラウドベースの対応物と比較して、依然として遅れをとっています 。ハイエンドの開発者マシン上でも、小規模モデルはその機能に限界があります 。私たちは、それらが複雑なプロンプトに苦労し、より大きな問題に必要なコンテキストウィンドウを欠いており、ツール統合や関数呼び出しをトリガーできないことが多いことを発見しました 。これらの機能は、現在のコーディングアシスタンスの最先端であるエージェントワークフローにとって特に不可欠です 。そのため、期待を低く設定して進めることを推奨しますが、ローカルで有効な機能もいくつかあります 。一部の人気IDEは、Xcodeの予測コード補完やJetBrainsの全行コード補完など、小規模モデルをそのコア機能に組み込んでいます 。また、Qwen Coderのようなローカルで実行可能なLLMは、ローカルのインライン提案や簡単なコーディングクエリの処理において一歩前進しています 。Ollamaのようなランタイムを介したローカルモデルの統合をサポートするContinueでこれらの機能をテストできます 。
感想: IntelliJの全行コード補間は、ローカルLLMなのか。
20. AIによるペアプログラミングの代替
コーディングアシスタントについて話すとき、ペアプログラミングの話題は必然的に出てきます 。私たちの職業はそれと愛憎関係にあります。ある人はそれを誓い、他の人はそれが我慢できません 。コーディングアシスタントは今、人間が別の人間ではなくAIとペアを組んで、チームのために同じ結果を得ることができるのか、という疑問を提起します 。GitHub Copilotさえも自らを「AIペアプログラマー」と呼んでいます 。コーディングアシスタントがペアプログラミングのいくつかの利点をもたらすとは考えますが、ペアプログラミングをAIで完全に置き換えることには反対します 。コーディングアシスタントをペアプログラマーと位置付けることは、ペアリングの主要な利点の1つ、つまり個人貢献者だけでなくチームを向上させることを見落としています 。コーディングアシスタントは、行き詰まったときの助け、新しいテクノロジーの学習、オンボーディング、戦術的な作業を高速化して戦略的な設計に集中できるようにするなどの利点を提供できます 。しかし、作業中の進行を低く保つこと、引き継ぎと再学習を減らすこと、継続的統合を可能にすること、集合的なコード所有権を改善することなど、チームコラボレーションの利点には何の役にも立ちません 。
感想: 「チームコラボレーションの利点には何の役にも立ちません 。」と言い切っている。
22. SAFe™
SAFe™（Scaled Agile Framework®）の継続的な採用が見られます 。また、SAFeの過度に標準化されたフェーズゲートプロセスが摩擦を生み出し、サイロ化を促進し、トップダウンの統制がバリューストリームにおける無駄を生み出し、エンジニアリング人材の創造性を阻害し、チームの自律性と実験性を制限するということも継続的に観察しています 。採用の主な理由の一つは、組織をアジャイルにすることの複雑さにあり、企業はSAFeのようなフレームワークがアジャイルになるためのシンプルでプロセスベースの近道を提供することを期待しています 。SAFeが広く採用されていることを踏まえ、クライアントをよりよくサポートするために100人以上のThoughtworksコンサルタントを育成しました 。この深い知識と試行錯誤にもかかわらず、複雑な問題にはシンプルな解決策がない場合もあるという考えに至り、包括的な変更プログラムと連携して機能する、よりリーンで価値主導のアプローチとガバナンスを推奨し続けています 。Scaled Agile Framework®およびSAFe™は、Scaled Agile, Inc.の商標です 。
感想: やっぱりアジャイルをスケールさせるのって難しいよね。
Platforms
採用（Adopt）
23. GitLab CI/CD
GitLab CI/CDは、コード統合とテストからデプロイと監視まで、GitLab内の完全に統合されたシステムへと進化しました 。マルチステージパイプライン、キャッシュ、並列実行、オートスケーリングランナーなどの機能を備え、複雑なワークフローをサポートし、大規模なプロジェクトや複雑なパイプラインのニーズに適しています 。特に、組み込みのセキュリティおよびコンプライアンスツール（SASTやDAST分析など）により、高コンプライアンス要件のあるユースケースに最適です 。また、Kubernetesとシームレスに統合し、クラウドネイティブなワークフローをサポートし、リアルタイムロギング、テストレポート、トレーサビリティを提供して可観測性を強化します 。
感想: まだAdoptじゃなかったんだ。
25. ABsmartly
ABsmartlyは、迅速で信頼性の高い意思決定のために設計された高度なA/Bテストおよび実験プラットフォームです 。その際立った特徴は、従来のA/Bテストツールと比較してテスト結果を最大80%高速化するグループシーケンシャルテスト（GST）エンジンです 。このプラットフォームは、リアルタイムレポート、詳細なデータセグメンテーション、およびAPIファーストのアプローチによるシームレスなフルスタック統合を提供し、ウェブ、モバイル、マイクロサービス、MLモデルにわたる実験をサポートします 。ABsmartlyは、スケーラブルでデータ駆動型の実験における主要な課題に対処し、より迅速なイテレーションとよりアジャイルな製品開発を可能にします 。そのゼロラグ実行、詳細なセグメンテーション機能、およびマルチプラットフォーム実験のサポートは、実験文化をスケールアップし、データに基づいたイノベーションを優先したい組織にとって特に価値があります 。テストサイクルを大幅に短縮し、結果分析を自動化することで、ABsmartlyは、従来のA/Bテストプラットフォームよりも効率的に機能とユーザーエクスペリエンスを最適化するのに役立ちました 。
感想: 技術の引き出しとして持っておきたい。
26. Dapr
Daprは、前回Radarで紹介されて以来、大幅に進化しました 。ジョブスケジューリング、仮想アクター、より洗練された再試行ポリシー、オブザーバビリティコンポーネントなど、多くの新機能が含まれています 。ビルディングブロックのリストは、ジョブ、暗号化などで増え続けています 。当社のチームは、mTLSとディストロレスイメージのサポートなど、セキュアなデフォルトに対する重視も増加していることを指摘しています 。全体として、Daprには満足しており、今後の発展を楽しみにしています 。
感想: えらく褒めている。前回の記事。
Dapr (Distributed Application Runtimeの略) は、クラウド上で動作するレジリエントでステートレス、ステートフルなマイクロサービスの構築を支援する。サービスメッシュと混同する人もいるかもしれませんが、これはアプリケーションと並行して別のプロセスとして実行されるサイドカーアーキテクチャを使用するためです。Daprはよりアプリケーション指向であり、分散アプリケーションの構築に必要なフォールトトレランスと接続性のカプセル化に重点を置いている。たとえば、Daprは、サービス呼び出しやメッセージpub/subから分散ロックまで、分散通信の一般的なパターンである複数のビルディングブロックを提供します。私たちのチームの1つは、最近のプロジェクトでDaprを評価しました。良い経験をしたことから、将来的には他のプロジェクトにも取り入れたいと考えています。
確かに、pub/sub、分散ロックとかのうまいやり方ができるのならいいな。
28. Grafana Loki
Grafana Lokiは、Prometheusにインスパイアされた、水平スケーラブルで高可用性のマルチテナントログ集約システムです 。Lokiは、各ログストリームのラベルのセットとして、ログに関するメタデータのみをインデックス化します 。ログデータは、S3、GCS、Azure Blob Storageなどのブロックストレージソリューションに保存されます 。これにより、Lokiは競合製品と比較して運用上の複雑さとストレージコストの削減を約束します 。予想通り、GrafanaおよびGrafana Alloyと密接に統合されていますが、他の収集メカニズムも使用できます 。Loki 3.0では、ネイティブOpenTelemetryのサポートが導入され、OpenTelemetryシステムとの取り込みと統合がエンドポイントの設定と同じくらい簡単になりました 。また、シャッフルシャーディングによるテナント分離など、高度なマルチテナンシー機能も提供しており、問題のあるテナント（重いクエリや停止など）がクラスター内の他のテナントに影響を与えるのを防ぎます 。Grafanaエコシステムの開発を追っていない場合は、急速に進化しているため、今すぐ確認するのに最適な時期です 。
感想: ログのストレージコストって結構馬鹿にならない金額になる。
評価（Assess）
40. モデルコンテキストプロトコル (MCP)
プロンプティングにおける最大の課題の1つは、AIツールがタスクに関連するすべてのコンテキストにアクセスできるようにすることです 。多くの場合、このコンテキストは、Wiki、課題トラッカー、データベース、可観測性システムなど、私たちが毎日使用するシステム内にすでに存在しています 。AIツールとこれらの情報源とのシームレスな統合は、AI生成出力の品質を大幅に向上させることができます 。AnthropicによってリリースされたオープンスタンダードであるModel Context Protocol（MCP）は、LLMアプリケーションを外部データソースおよびツールと統合するための標準化されたフレームワークを提供します 。これはMCPサーバーとクライアントを定義しており、サーバーはデータソースにアクセスし、クライアントはこのデータを統合してプロンプトを強化します 。多くのコーディングアシスタントはすでにMCP統合を実装しており、MCPクライアントとして機能できます 。MCPサーバーは2つの方法で実行できます。ローカルで、ユーザーのマシンで実行されるPythonまたはNodeプロセスとして、またはリモートで、MCPクライアントがSSEを介して接続するサーバーとして（ただし、リモートサーバーバリアントの使用はまだ見られていません） 。現在、MCPは主に最初の方法で使用されており、開発者がオープンソースのMCPサーバー実装をクローンしています 。ローカルで実行されるサーバーは、サードパーティの依存関係を回避する巧妙な方法を提供しますが、非技術系ユーザーにはアクセスしにくく、ガバナンスや更新管理などの課題を抱えています 。とはいえ、この標準が将来、より成熟したユーザーフレンドリーなエコシステムに進化することは容易に想像できます 。
感想: いずれはMCPもSaaSのプロトコルとして提供されるのだろうな。
45. Supabase
Supabaseは、スケーラブルでセキュアなバックエンドを構築するためのオープンソースのFirebase代替品です 。PostgreSQLデータベース、認証、インスタントAPI、Edge Functions、リアルタイムサブスクリプション、ストレージ、ベクトル埋め込みなど、統合されたサービススイートを提供します 。Supabaseは、バックエンド開発を効率化し、開発者がオープンソース技術のパワーと柔軟性を活用しながら、フロントエンドエクスペリエンスの構築に集中できるようにすることを目指しています 。Firebaseとは異なり、SupabaseはPostgreSQL上に構築されています 。プロトタイプ作成やMVPに取り組んでいる場合、Supabaseは検討する価値があります。プロトタイプ作成段階の後で別のSQLソリューションに移行するのが容易になるためです 。
感想: セットアップや学習のコストが低ければ使ってみたい。使ってみたら、結局本番までいく事例が続出しそう。
46. Synthesized
ソフトウェア開発における共通の課題は、開発環境およびテスト環境用のテストデータを生成することです 。理想的には、テストデータは個人を特定できる情報や機密情報を公開することなく、できるだけ本番環境に近いものであるべきです 。これは単純に聞こえるかもしれませんが、テストデータ生成は決して単純ではありません 。だからこそ、既存の本番データをマスクしてサブセット化したり、統計的に関連性の高い合成データを生成したりできるプラットフォームであるSynthesizedに注目しています 。これはビルドパイプラインに直接統合され、ハッシュ化、ランダム化、ビンニングなどの不可逆的なデータ難読化技術を通じて、属性ごとの匿名化を提供するプライバシーマスキングを提供します 。Synthesizedは、パフォーマンステスト用に大量の合成データを生成することもできます 。義務的なGenAI機能も含まれていますが、そのコア機能は開発チームにとって現実的で根強い課題に対処しており、探求する価値があります 。
感想: パフォーマンステストように大量のデータが欲しい事は、数年に一回はある。技術の引き出しとしては触っておきたい。
49. VectorChord
VectorChordは、pgvecto.rsの後継として開発された、ベクトル類似性検索のためのPostgreSQL拡張機能です 。オープンソースで、pgvectorデータ型と互換性があり、ディスク効率的で高性能なベクトル検索のために設計されています 。計算要求を大幅に削減しながら、高速でスケーラブルかつ正確なベクトル検索を可能にするために、反転ファイルインデックス（IVF）とRaBitQ量子化を採用しています 。この分野の他のPostgreSQL拡張機能と同様に、PostgreSQLエコシステムを活用することで、標準的なトランザクション操作と並行してベクトル検索を行うことができます 。まだ初期段階ですが、VectorChordはベクトル検索ワークロードの評価に値します 。
感想: RAGを触ってみたいから、この手のPostgreSQL拡張について調べておきたい。
Tools
採用（Adopt）
52. uv
前回のRadar以来、uvに関する経験を重ね、チームからのフィードバックは圧倒的に好意的でした 。uvはRustで書かれた次世代のPythonパッケージおよびプロジェクト管理ツールであり、その主な価値提案は「非常に高速」であることです 。ベンチマークでは他のPythonパッケージマネージャーを大差で上回り、ビルドおよびテストサイクルを高速化し、開発者エクスペリエンスを大幅に向上させます 。パフォーマンス以外にも、uvは統一されたツールセットを提供し、Poetry、pyenv、pipxなどのツールを効果的に置き換えます 。ただし、パッケージ管理ツールに関する懸念は依然として残っています。強力なエコシステム、成熟したコミュニティ、長期的なサポートが不可欠です 。uvが比較的新しいことを考えると、Adoptリングへの移行は大胆なものです 。とはいえ、多くのデータチームはPythonのレガシーなパッケージ管理システムから移行したがっており、最前線の開発者はuvを今日利用可能な最高のツールとして一貫して推奨しています 。
感想: 既に使っているけど、確かにいい感じ。
試用（Trial）
54. Claude Sonnet
Claude Sonnetは、コーディング、ライティング、分析、視覚処理に優れた高度な言語モデルです 。ブラウザ、ターミナル、ほとんどの主要なIDEで利用可能であり、GitHub Copilotとも統合されています 。執筆時点では、ベンチマークによるとバージョン3.5と3.7で以前のモデル、初期のClaudeモデルを含むものよりも優れたパフォーマンスを発揮しています 。また、チャートの解釈や画像からのテキスト抽出にも長けており、ブラウザUIの「Artifacts」機能のように、コードスニペットやHTMLデザインなどの動的なコンテンツを生成し、対話するための開発者向けのエクスペリエンスを提供しています 。私たちはソフトウェア開発でClaude Sonnetのバージョン3.5を extensivelyに利用し、様々なプロジェクトで生産性を大幅に向上させることを確認しました 。特に新規プロジェクト、コラボレーションによるソフトウェア設計、アーキテクチャに関する議論で優れています 。AIモデルをコーディングアシスタンスにとって「安定している」と呼ぶのはまだ早すぎるかもしれませんが、Claude Sonnetは私たちがこれまで作業してきた中で最も信頼性の高いモデルの1つです 。執筆時点では、Claude 3.7もリリースされており、有望ですが、まだ本番環境で完全にテストしていません 。
感想: Claude Codeを使ってみたけど、JetBrainsのJunieの方が良さげ。もうしばらくは試してみた方がいいのかな。
55. Cline
Clineは、現在、教師付きソフトウェアエンジニアリングエージェントの分野で最も有力な候補の1つであるオープンソースのVSCode拡張機能です 。開発者は、Clineチャットから直接実装を駆動でき、すでに使用しているIDEとシームレスに統合します 。Plan & Actモード、透明なトークン使用量、MCP統合などの主要な機能は、開発者がLLMと効果的に対話するのに役立ちます 。Clineは、特にClaude 3.5 Sonnetとの組み合わせで、複雑な開発タスクを処理する高度な能力を実証しました 。大規模なコードベースをサポートし、ヘッドレスブラウザテストを自動化し、バグを積極的に修正します 。クラウドベースのソリューションとは異なり、Clineはデータをローカルに保存することでプライバシーを強化します 。そのオープンソースの性質は、透明性を高めるだけでなく、コミュニティ主導の改善も可能にします 。ただし、開発者はトークンの使用コストに注意する必要があります。Clineのコードコンテキストオーケストレーションは非常に効果的ですが、リソースを大量に消費するためです 。もう1つの潜在的なボトルネックはレート制限であり、ワークフローを遅らせる可能性があります 。これが解決されるまでは、より良いレート制限を提供するOpenRouterのようなAPIプロバイダーを使用することをお勧めします 。
56. Cursor
AIファーストのコードエディターであるCursorには引き続き感銘を受けています。競争の激しいAIコーディングアシスタンスの分野で引き続きリーダーであり続けています 。そのコードコンテキストオーケストレーションは非常に効果的であり、カスタムAPIキーを使用するオプションを含む幅広いモデルをサポートしています 。Cursorチームは、他のベンダーに先駆けて革新的なユーザーエクスペリエンス機能を考案することが多く、git diff、以前のAI会話、ウェブ検索、ライブラリドキュメント、MCP統合の参照など、チャットに豊富なコンテキストプロバイダーを含めています 。ClineやWindsurfなどのツールと同様に、Cursorは強力なエージェント型コーディングモードでも際立っています 。このモードにより、開発者はAIチャットインターフェースから直接実装をガイドでき、ツールは自律的にファイルを読み書きし、コマンドを実行します 。さらに、生成されたコードのリントエラーやコンパイルエラーを検出し、積極的に修正するCursorの能力を高く評価しています 。
感想: MCP統合は興味があるけど、VSCodeのフォークってのがな。IntelliJと統合してある方がいいな。プログラミングに適切なMCPサーバが必要なのかな。自分で各種パッケージとかの最新バージョンを返すMCPサーバを作ってみるのは面白いかも。
57. D2
D2は、テキストから図を作成・カスタマイズできるオープンソースのdiagrams-as-codeツールです 。シンプルで宣言的な構文により、コンパクトさよりも可読性を優先したD2図スクリプト言語を導入しています 。D2にはデフォルトのテーマが付属し、Mermaidと同じレイアウトエンジンを活用しています 。当社のチームは、ソフトウェアドキュメントやアーキテクチャ図用に特別に設計されたその軽量な構文を高く評価しています 。
感想: Mermaidみたいな、大量の要素があるとスクロールしまくりの、しまりの無い図が出てくるから、まだまだPlantUMLだな。
67. Tuple
Tupleは、リモートペアプログラミングに最適化されたツールで、もともとSlackのScreenheroが残したギャップを埋めるために設計されました 。前回Radarで言及されて以来、その採用は広がり、以前の癖や制約が解消され、Windowsもサポートされるようになりました 。主な改善点として、デスクトップ共有の機能強化と組み込みのプライバシー機能があり、ユーザーはブラウザウィンドウなどのツールを共有しながら、プライベートなアプリウィンドウ（テキストメッセージなど）を非表示にすることができます 。以前は、UIの制約により、Tupleは汎用的なコラボレーションツールというよりもペアプログラミングツールのように感じられました 。これらの更新により、ユーザーはIDEを超えたコンテンツでコラボレーションできるようになりました 。ただし、リモートペアがデスクトップ全体にアクセスできることに注意することが重要です 。適切に設定されていない場合、特にペアが信頼できない場合は、セキュリティ上の懸念が生じる可能性があります 。使用前にTupleのプライバシー設定、ベストプラクティス、エチケットについてチームを教育することを強く推奨します 。開発ワークフローでTupleの最新バージョンを試すことをお勧めします 。これは、低遅延のペアリング、直感的なUX、および大幅なユーザビリティの改善を提供する、当社の実用的なリモートペアリング推奨と一致しています 。
感想: 「適切に設定されていない場合、特にペアが信頼できない場合は、セキュリティ上の懸念が生じる可能性があります 。」。基本的には信用できる人としかペアプロしないけど、やっぱり… $30/user/monthか… 高い。一日中、ペアプロで作業するなら安いけど。たまに使用するだけだとね。
評価（Assess）
69. AnythingLLM
Anything LLMは、大規模なドキュメントやコンテンツとチャットするためのオープンソースのデスクトップアプリケーションで、LLMとベクトルデータベースとのすぐに使える統合によって支えられています 。埋め込みモデルのプラグイン可能なアーキテクチャを持ち、ほとんどの商用LLMだけでなく、Ollamaで管理できるオープンウェイトモデルでも使用できます 。RAGに加えて、さまざまなスキルを作成し、エージェントとして整理して、カスタムタスクやワークフローを実行できます 。ドキュメントとそれらとのインタラクションをさまざまなワークスペースで整理でき、それらは異なるコンテキストを持つ長期間持続するスレッドとして機能します 。最近では、簡単なDockerイメージでマルチユーザーWebアプリケーションとしてデプロイすることも可能になりました 。私たちのチームのいくつかは、ローカルのパーソナルアシスタントとしてこれを使用しており、強力で便利なユーティリティであると感じています 。
感想: ちょっと動かしてみたい。
75. ModernBERT
BERT（Bidirectional Encoder Representations from Transformers）の後継であるModernBERTは、幅広い自然言語処理（NLP）タスク用に設計された、次世代のエンコーダーオンリー型トランスフォーマーモデルファミリーです 。ドロップイン置換として、ModernBERTはパフォーマンスと精度の両方を向上させるとともに、BERTのいくつかの制限、特にAlternating Attentionのおかげで劇的に長いコンテキスト長をサポートします 。NLPのニーズを持つチームは、汎用生成モデルにデフォルト設定する前にModernBERTを検討すべきです 。
感想: BERTと何が違う？
76. OpenRouter
OpenRouterは、複数の大規模言語モデルにアクセスするための統一APIです 。主流のLLMプロバイダー向けの単一の統合ポイントを提供し、実験を簡素化し、ベンダーロックインを減らし、最も適切なモデルにリクエストをルーティングすることでコストを最適化します 。ClineやOpen WebUIのような人気のあるツールは、OpenRouterをエンドポイントとして使用しています 。私たちのRadarの議論中に、OpenRouterがこのカプセル化レイヤーの上に利益モデルとして価格マークアップを追加する必要があることを考えると、ほとんどのプロジェクトが本当にモデルを切り替える必要があるのか疑問に思いました 。しかし、OpenRouterがコストを最適化するのに役立つさまざまな負荷分散戦略を提供することも認識しています 。特に便利な機能の1つは、APIレート制限を回避できることです 。アプリケーションが単一のLLMプロバイダーのレート制限を超えた場合、OpenRouterはこの制限を突破し、より良いスループットを達成するのに役立ちます 。
感想: 手数料が取られるけど、各社のAPIをテストする時は個別にAPI料金をチャージするよりは安いかも。
78. System Initiative
私たちは引き続きSystem Initiativeに期待しています 。この実験的なツールは、DevOps作業の根本的に新しい方向性を表しています 。このツールに注ぎ込まれた創造的な思考を非常に高く評価しており、他の人々がインフラストラクチャ・アズ・コードのアプローチの現状を打破することを奨励してくれることを願っています 。System Initiativeは現在ベータ版を終了し、Apache 2.0ライセンスの下で無料でオープンソースとして利用可能です 。ツールの開発者は本番インフラストラクチャの管理にこれを使用していますが、大企業の要求を満たす規模に達するにはまだ時間がかかります 。しかし、DevOpsツールへのまったく異なるアプローチを体験するために、引き続きチェックする価値があると考えています 。
感想: 「根本的に新しい方向性」と来たか。昨年('24.04)の内容は以下の通り。
近年、インフラストラクチャコーディングツールとしてのTerraformの支配に挑戦するものはほとんど現れていない。Pulumi、CDK、最近ではWingなどの代替手段が登場しているが、Terraformのモジュール式の宣言型パラダイムが最も永続的であることが証明されている。実際、これらのアプローチはすべて、モノリシックなインフラストラクチャを作成するモジュールコードという共通の目標を共有しています。System Initiativeは、DevOps作業の根本的な新しい方向性を示す新しい実験的なツールです。System Initiativeをインフラストラクチャのデジタルツインと見なす方法の1つです。システムイニシアチブの状態をインタラクティブに変更すると、対応する変更セットが生成され、インフラストラクチャ自体に適用できます。同様に、インフラストラクチャへの変更は、システムイニシアチブの状態に反映されます。このアプローチの大きな利点の1つは、アプリケーションのデプロイや可観測性などのために作成されるコラボレーション環境です。エンジニアは、環境全体をグラフィカルに表現したユーザーインターフェイスを介してSystem Initiativeと対話します。クラウドインフラストラクチャの管理に加えて、コンテナ、スクリプト、ツールなどの管理にも使用できます。この種のGUIツールには一般的に懐疑的ですが、System Initiativeを拡張して、新しいアセットを処理したり、TypeScriptコードを使用してポリシーを適用したりすることができます。私たちは、このツールに込められた創造的な考え方を本当に気に入っており、他の人たちがコードとしてのインフラストラクチャのアプローチの現状を打破するようになることを願っています。System InitiativeはApache 2.0ライセンスの下でフリーかつオープンソースであり、現在オープンベータである。メンテナー自身は、まだこのツールを本番環境で使用することを推奨していませんが、DevOpsツールへのまったく異なるアプローチを体験するために、現在の状態をチェックする価値があると思います。
どの程度の種類のリソースがサポートされているのかによるのかな。変更の差分は見やすい？
81. Windsurf
Windsurfは、CodeiumによるAIコーディングアシスタントで、そのエージェント機能が際立っています 。CursorやClineと同様に、開発者はAIチャットから実装を駆動でき、コードのナビゲートと変更、コマンドの実行が可能です 。エージェントモード向けに興味深い新機能や統合を頻繁にリリースしています 。例えば最近では、エージェントがDOM要素やブラウザコンソールに簡単にアクセスできるブラウザプレビューや、必要に応じてWindsurfがインターネットでドキュメントやソリューションを検索できるウェブ検索機能がリリースされました 。Windsurfはさまざまな人気モデルへのアクセスを提供し、ユーザーはウェブ検索、ライブラリドキュメント、MCP統合を補足的なコンテキストプロバイダーとしてアクティブ化し、参照できます 。
感想: 「必要に応じてWindsurfがインターネットでドキュメントやソリューションを検索できるウェブ検索機能がリリース」。これは本当に必要。
82. YOLO
Ultralyticsが開発したYOLO（You Only Look Once）シリーズは、コンピュータビジョンモデルの進歩を続けています 。最新のリリースであるYOLO11は、以前のバージョンと比較して精度と効率の両方で大幅な改善を実現しています 。YOLO11は、最小限のリソースで高速に画像分類を実行できるため、エッジデバイスでのリアルタイムアプリケーションに適しています 。また、ポーズ推定、物体検出、画像セグメンテーション、その他のタスクを同じフレームワークで実行できる機能が非常に強力であることもわかりました 。この重要な開発は、特定のタスクには汎用AIモデル（LLMなど）よりも「従来型」の機械学習モデルを使用する方が強力である場合があることを私たちに思い出させます 。
感想: そのうち、触ってみたい。
Languages and Frameworks
採用（Adopt）
83. OpenTelemetry
OpenTelemetryは、オブザーバビリティの業界標準として急速に普及しています 。OpenTelemetryプロトコル（OTLP）仕様のリリースにより、トレース、メトリクス、ログを処理する標準化された方法が確立され、分散ソリューションの監視および相互運用性の要件が増大するにつれて、複数の統合や大規模な書き換えの必要性が減少しました 。OpenTelemetryがログとプロファイリングのサポートを拡大するにつれて、OTLPはすべてのテレメトリデータ全体で一貫した転送フォーマットを保証し、マイクロサービスアーキテクチャの計装を簡素化し、フルスタックオブザーバビリティをより利用しやすくスケーラブルにします 。Datadog、New Relic、Grafanaなどのベンダーに採用されているOTLPは、組織が柔軟でベンダーに依存しないオブザーバビリティスタックを構築し、プロプライエタリなソリューションに縛られることなく利用できるようにします 。gzipとzstd圧縮をサポートしており、テレメトリデータのサイズを削減し、帯域幅の使用量を低減します。これは、大量のテレメトリデータを処理する環境にとって重要な利点です 。長期的な成長のために設計されたOTLPは、OpenTelemetryが堅牢で将来性のある標準であり続けることを保証し、テレメトリ転送の事実上の選択肢としての地位を確固たるものにしています 。
感想: 一度、本で勉強しないと。
試用（Trial）
86. Hasura GraphQL engine
Hasura GraphQL engineは、さまざまなデータソース上で高品質のAPIを構築、実行、管理するプロセスを簡素化するユニバーサルデータアクセス層です 。さまざまなデータベース（PostgreSQL、MongoDB、ClickHouseなど）やデータソース上で即座にGraphQL APIを提供し、開発者が必要なデータのみを迅速かつ安全にフェッチできるようにします 。サーバーサイドのリソース集約にHasuraを使ってGraphQLを実装するのは簡単だと感じており、複数のデータ製品プロジェクトに適用してきました 。ただし、その強力なフェデレーションクエリと統合スキーマ管理については、引き続き慎重な姿勢を保っています 。最近の注目すべき追加機能として、HasuraのPromptQL機能があります。これは、開発者がLLMを活用して、より自然で直感的なデータインタラクションを実現できるようにするものです 。
感想: GraphQLは使ってみたいけど、メンテナンスが面倒そうだから尻込みしていた。楽に管理できるならいいかも。
88. MarkItDown
MarkItDownは、さまざまな形式（PDF、HTML、PowerPoint、Word）をMarkdownに変換し、テキストの可読性とコンテキスト保持を向上させます 。LLMは、見出しやセクションなどの書式設定の手がかりからコンテキストを導き出すため、Markdownは構造を維持して理解を深めるのに役立ちます 。RAGベースのアプリケーションでは、私たちのチームはMarkItDownを使用してドキュメントをMarkdownに前処理し、論理的なマーカー（見出し、サブセクション）がそのまま維持されるようにしました 。埋め込み生成の前に、構造を認識したチャンキングは、特に複雑なドキュメントの場合、クエリ応答の明確さを向上させる、完全なセクションコンテキストを維持するのに役立ちました 。ドキュメントで広く使用されているMarkdownは、MarkItDownのCLIも開発者の生産性ツールとして価値のあるものにしています 。
感想: RAGの前処理に必須のような。
89. Module Federation
Module Federationは、マイクロフロントエンド間で共有モジュールと依存関係の重複排除を指定することを可能にします 。バージョン2.0では、webpackから独立して機能するように進化しました 。この更新により、フェデレーションランタイム、新しいプラグインAPI、ReactやAngularなどの人気フレームワーク、RspackやViteなどの人気バンドラーのサポートなど、主要な機能が導入されました 。Module Federationを採用することで、大規模なWebアプリケーションをより小さく、管理しやすいマイクロフロントエンドに分割でき、異なるチームが依存関係やコンポーネントを効率的に共有しながら、独立して開発、デプロイ、スケーリングできるようになります 。
感想: マイクロフロントエンドは、チーム毎に依存関係が重複しそうで嫌だなと思っていたけど、これならよさそう。
90. Prisma ORM
Prisma ORMは、Node.jsおよびTypeScriptアプリケーションでデータベースを扱うのを簡素化するオープンソースのデータベースツールキットです 。データベースアクセスへのモダンで型安全なアプローチを提供し、データベーススキーマの移行を自動化し、直感的なクエリAPIを提供します 。一般的なORMとは異なり、PrismaORMはデコレータやクラスなしでプレーンなJavaScriptオブジェクトを使用してデータベース型を定義します 。Prisma ORMに関する私たちの経験は肯定的です。一般的なTypeScript開発環境により良く合致するだけでなく、関数型プログラミングパラダイムともきれいに統合されていることを発見しました 。
感想: 前に使った事があるけど、良かった。ただし、その後TypeScript自体から離れるようにしているけど。
評価（Assess）
92. Android XR SDK
Googleは、SamsungおよびQualcommと協力して、XRヘッドセット用に設計された新しいオペレーティングシステムであるAndroid XRを導入しました 。メガネやその他のデバイスのサポートも計画されています。ほとんどのAndroidアプリは変更なし、または最小限の変更でサポートされますが、新しい空間アプリをゼロから構築するか、既存のアプリを「空間化」することが構想されています 。新しいAndroid XR SDKは、そのようなプロジェクトの主要なSDKとして位置付けられており、GoogleはSDKにバンドルされているツールとテクノロジーの選択方法に関するガイダンスを提供しています 。現在、開発者プレビューが利用可能です 。
感想: DaydreamのSDKを以前触ったけど、あれみたいにならなければいいけど… また、手を出してみるか。これはLLMは学習していないから自分でコードを書くのか…
93. Browser Use
Browser Useは、LLMベースのAIエージェントがWebブラウザを使用し、WebアプリケーションにアクセスできるようにするオープンソースのPythonライブラリです 。ブラウザを制御し、ナビゲーション、入力、テキスト抽出などの手順を実行できます 。複数のタブを管理できるため、複数のWebアプリ間で協調したアクションを実行できます 。LLMベースのエージェントがWebコンテンツにアクセスし、それに対してアクションを実行し、結果を得る必要があるシナリオに役立ちます 。このライブラリは、さまざまなLLMと連携できます 。Playwrightを活用してブラウザを制御し、視覚的理解とHTML構造抽出を組み合わせてWebインタラクションを改善します 。このライブラリはマルチエージェントシナリオで注目を集めており、エージェントがWebインタラクションを伴う複雑なワークフローで協力できるようにします 。
感想: 複数タブを使って面白いことができそう。
94. CrewAI
CrewAIは、複雑なタスクを達成するために連携できるAIエージェントを構築および管理するのに役立つプラットフォームです 。これは、それぞれ独自の特別なスキルを持つAIワーカーのクルーを作成し、共通の目標を達成するために協力できるようにする方法と考えることができます 。以前、RadarのLLMパワード自律エージェントのセクションで言及しました 。オープンソースのPythonライブラリに加えて、CrewAIは現在、エンタープライズソリューションも提供しており、組織はプロモーションコードの自動検証からトランザクション障害や顧客サポートクエリの調査まで、現実世界のビジネスケース向けにエージェントベースのアプリケーションを作成し、クラウドインフラストストラクチャで実行し、SharepointやJIRAなどの既存のデータソースに接続できます 。CrewAIを複数回使用して、本番環境の課題に取り組んできました 。エージェントの状況は急速に進化し続けていますが、CrewAIを評価（Assess）に配置することに自信を持っています 。
感想: JIRAとかにもアクセスできるのか。アクセス権周りはどうしているのだろう。
96. FastGraphRAG
FastGraphRAGは、高い検索精度とパフォーマンスのために設計されたGraphRAGのオープンソース実装です 。パーソナライズドページランクを使用して、グラフ内のすべての関連ノードの中から最も関連性の高いノードにグラフナビゲーションを制限し、検索精度を向上させ、LLM応答品質を改善します 。また、グラフの視覚的表現も提供し、ユーザーがノード関係と検索プロセスを理解するのに役立ちます 。増分更新をサポートしているため、動的で進化するデータセットに適しています 。大規模なGraphRAGユースケース向けに最適化されており、リソース消費を最小限に抑えながらパフォーマンスを向上させます 。
感想: RAG関連の実装っていっぱいあって、どれがいいのだろう。
99. Java post-quantum cryptography
現代の通信のほとんどを保護する非対称暗号化の核心には、数学的に難しい問題があります 。しかし、今日のアルゴリズムで使用されている問題は、量子コンピューターで簡単に解決できるため、代替手段の研究が進んでいます 。格子ベース暗号は、現在最も有望な候補です。暗号学的に関連する量子コンピューターはまだ数年先ですが、数十年間にわたって安全性を維持する必要があるアプリケーションの場合、耐量子暗号を検討する価値があります 。また、量子コンピューターが利用可能になったときに復号化するために、暗号化されたデータが今日記録されるリスクもあります 。Java耐量子暗号は、3月下旬に一般提供が予定されているJDK 24で最初のステップを踏み出します 。このリリースには、主要なカプセル化メカニズムとデジタル署名アルゴリズムを実装するJEP 496とJEP 497が含まれており、これらは標準ベースであり、将来の量子コンピューティング攻撃に耐性があるように設計されています 。Open Quantum SafeプロジェクトのliboqsはJNIラッパー付きのCベースの実装を提供していますが、ネイティブJava実装も登場しているのは心強いことです 。
感想: JDK [24はリリースされたので、調べてみたい。この辺を起点に。
101. PydanticAI
LLMを基盤とするアプリケーションやエージェントを構築する技術が急速に進化するにつれて、そのようなアプリケーションを構築およびオーケストレーションするためのフレームワークは、時代を超越した適切な抽象化を維持するのに苦労することがよくあります 。PydanticAIは、不必要な複雑さを回避しつつ実装を簡素化することを目的とした、この分野の最新の参入者です 。人気のあるPydanticの作成者によって開発され、以前のフレームワーク（その多くはすでにPydanticに依存している）から得られた教訓に基づいて構築されています 。万能ツールになろうとするのではなく、PydanticAIは軽量でありながら強力なアプローチを提供します 。すべての主要なモデルAPIと統合し、組み込みの構造化出力処理を含み、複雑なエージェントワークフローを管理するためのグラフベースの抽象化を導入しています 。
Discussion