2 ポイント 投稿者 GN⁺ 2025-04-08 | まだコメントはありません。 | WhatsAppで共有
  • 大規模システムやAIが高速に生成したコードは、人間が継続的に読んで理解することが難しくなっており、Glamorous Toolkitは決定論的コンテキストツールによってシステム理解を支援する Moldable Development Environment を志向している
  • 質問ごとに必要なシステム断面を圧縮するコンテキストツールを作り、これを関連するオブジェクトや状況に結び付けて、必要な瞬間にだけ有効化する方式である
  • 内蔵のエージェントハーネスは、会話コンテキスト・ツール・構造化出力をスクリプトで定義し、OpenAI、Anthropic、Ollama、または独自プロバイダーとともに利用できる
  • 活用範囲はレガシーシステム分析を超えて、ドメイン発見、API・データ・ログ探索、ドキュメント化、ドメインモデリング、コード書き換え、AI対話、ランタイム検査まで広い
  • MITライセンスの無料オープンソースであり、PharoベースのSmalltalkを中心としつつ、Rustや複数の言語・ランタイム分析へ拡張可能である

システムとAIを理解するための Moldable Development Environment

  • Glamorous Toolkit の目標は、システムについてより良く情報を得る方法を最適化することにある
  • システムは大きすぎ、AIはコードをあまりに速く生成するため、コードを読むことだけで理解する方法はボトルネックになる
  • 読解中心のアプローチの代わりに、問題の周辺にあるシステムを圧縮する決定論的コンテキストツールを使う
  • これらのツールは、人間とAIがシステムをより速く探索できるよう助け、1つの統合環境の中で直接作成したりAIと一緒に作成したりできる
  • 既存システムに関する質問には、コンテキストツールで構成されたナラティブを通じて答えられる

内蔵エージェントハーネス

  • プログラム可能なエージェント

    • スクリプトで会話のコンテキスト、ツール、構造化出力を定義できる
  • 拡張可能なエージェントメモリ

    • コードと例に結び付いた実行可能な説明によってコンテキストを定義する
    • コンテキストビューを活用して、エージェントメモリを任意のオブジェクトまで拡張できる
  • 説明可能なエージェント動作

    • AIが何をしたと述べるかをそのまま受け入れるのではなく、コンテキストビューを通じて決定論的に理解できる
  • テキストではないオブジェクト

    • ライブオブジェクトを会話に渡し、構造化されたオブジェクトを受け取ることができる
    • 各オブジェクトは、人間とAIが探索できるコンテキストビューを持つ
    • OpenAI、Anthropic、Ollama とともに利用でき、独自プロバイダーも作成できる

なぜコンテキストツールが必要なのか

  • ソフトウェアには形がなく、ソフトウェアシステム内のいかなるものもツールを通さなければ知覚できない
  • ツールはソフトウェアに形を与えるため、ツールを制御すれば知覚と理解も制御できる
  • ソフトウェアは非常にコンテキスト依存であるため、ツールもコンテキストを持っていなければ効果的ではない
  • 1つのソフトウェアシステムに単一の表現はない
    • コードのテキスト形式も入力媒体の偶然的な形にすぎない
    • 問題に応じて異なる表現が必要になる
  • Glamorous Toolkit は、予測しにくい多数のコンテキストツールを受け入れるため、インタラクティブで視覚的な演算子から成る言語のように設計されている
    • マイクロツールを低コストでプログラミングし、組み合わせられる
    • ツールをライブ環境の中でさまざまな方法で作成できる

ツール、圧縮、制御の反転

  • ツールは、計算と相互作用するためのインターフェースである
    • 設定エディタ、ランタイムデバッガ、APIインスペクタであり得る
    • 複雑なツールであることも、1つの質問に集中する単純なツールであることもある
    • 視覚的な場合も、プレーンテキストベースの場合もある
    • 汎用ツールである場合も、狭い入力にのみ関連するコンテキストツールである場合もある
  • 汎用ツールは広く適用できるが、すべてを似たように見せてしまうコストがある
  • ソフトウェアシステムの価値は常に具体的であるため、コンテキストツールはその価値をより効率的かつ快適に伝えられる
  • システム理解は結局のところ質問に答える過程である
    • 答えはシステム成果物の中にあるが、成果物は大きすぎて読みにくい
    • ツールは答えを得る方法を決定論的にエンコードする
    • ツールの結果は、その質問に対するシステムの圧縮のように機能する
  • すべての質問に決定論的コンテキストツールで答えるには、システムごとに数千のツールが必要になる
  • Glamorous Toolkit は、ユーザーがツールを明示的に呼び出す代わりに、関連コンテキストに結び付け、そのコンテキストと相互作用するときだけ有効化する
    • このコンテキストは、個別オブジェクトのような基本単位であることもある

典型的な Moldable Development の流れ

  • 具体的な質問から始める
  • 関連ツールがなければ新しく作る
  • 答えを解釈し、判断を下す
  • このプロセスを繰り返す

オブジェクトビューとナラティブ

  • オブジェクトに結び付いたビューは、ドキュメント化の単位になる
  • オブジェクトが自動例によって生成・テストされるなら、チュートリアルからアーキテクチャ制約、ビジネスプロセスまで、長く持続する概念を伝える定義済みナラティブを作れる
  • このナラティブは人間とAIの両方を対象に設計できる
  • 同じ構成要素が開発体験全体に統合されるため、コードとともに自動テストやリファクタリングが可能になる
  • 定義済みナラティブは再利用可能な断片だが、ソフトウェアのコンテキスト特性上、より大きな質問にオンデマンドで答える動的ナラティブも必要になる
    • クラスタ性能の調査
    • COBOLシステム構造の探索
  • ナラティブは、ドメインを含め、システムのさまざまな側面を表すあらゆるオブジェクトを扱える
  • 異なる背景や関心を持つステークホルダーを対象にできるため、環境がシステム関係者間の対話を媒介する

コンテキスト編集

  • コンテキスト化は、編集を含むシステムとのあらゆる相互作用へ拡張される
  • システムは複数の側面から成る
    • 技術
    • ドメインルール
    • 慣習
    • ライブラリ
    • インターフェース
    • テスト
    • 生成成果物
    • ランタイム動作
  • 編集は単なるテキスト入力ではなく、こうした側面の一部に影響を与える行為である
  • すべての変更は、その意味を決めるコンテキストの中で起こる
  • 汎用エディタはこのコンテキストを平坦化し、ユーザーにエディタのレベルで作業することを強いる
  • コンテキストエディタは、相互作用をユーザーのメンタルモデルに合ったレベルまで引き上げる

利用範囲と限界

  • Glamorous Toolkit は、システムを理解し変更するためのツール、ビュー、説明、ワークフローを作るために主に使われる
  • 代替アプリケーションプラットフォームではない
  • 大規模レガシーシステムにも使えるが、それ以外のさまざまなシナリオも含む
    • ドメイン発見
    • API探索
    • データ探索
    • ログ理解
    • ドキュメント化
    • ドメインモデリング
    • コード書き換え
    • AI対話
    • ランタイム検査
  • 標準ツールは汎用的な問題に有用である
  • 具体的なシステムの中で現れる特定の質問には、コンテキストツールが必要である

AI要約と決定論的ツール

  • システムに関する大半の質問は、システム情報に基づく決定論的な答えを必要とする
  • AI要約は便利かもしれないが、正確かどうか、あるいは代表性があるかどうかは分からず、説明可能でもない
  • エンジニアリング目的の答えには、正確性、代表性、説明可能性が重要である
  • 決定論的コンテキストツールにもバイアスはあり得るが、出力を解釈する前にそのバイアスを検査できる
  • 詳細は Rewilding Software Engineering 6章 を参照

実装と支援技術

  • Glamorous Toolkit を使うと、コンテキストツールをそれほど難しくなく作成できる
  • 環境は視覚的かつインタラクティブな演算子から成る言語のように作られており、ツールを簡単にプログラミングし、多様な方法で組み合わせられる
  • Glamorous Toolkit を開くと、開発過程で使われた6,000個以上のコンテキストツールを確認できる
  • ツールの潜在力を十分に活用するにはプログラミングが必要であり、主な方法は Smalltalk の中でも Pharo である
  • Smalltalk を主に使った理由は、使用中でも環境をライブで変更できるリフレクティブなシステムを提供するためである
  • 現在、Glamorous Toolkit のかなりの部分は Rust でも実装されており、複数の技術とともに動作する
  • Pharo のサポートは洗練されているが、他の技術や言語にも拡張できるよう設計されている
    • 解析可能なソースの例: Rust, Java, C#, Ruby/Rails, Python, TypeScript, JavaScript, React, COBOL
    • 連携可能なランタイムの例: GraphQL, Python, JavaScript, Gemstone
  • これらのサポートは標準で提供されており、各言語や技術のためにユーザー自身が作れる例として見ることもできる

ライセンスと資料

まだコメントはありません。

まだコメントはありません。