Jevが便利そうなのでエージェント用にスキルを作ってあげる

こんにちは。
台風ですね。午前中お出かけして午後からのんびりしようと思っていたのですが、朝からしっかり雨です。

さて、最近TypeSafe Jevという新しいタイプのAIモデルが現れましたね。
こういうのが出るたびに「何かに使えそう！」と思うのですが、その「何か」が具体的に思い浮かばないのがいつものパターンです。
いや、思い付きはするけどこういうのはすぐに誰かが作るんだろうなと思って待ってしまうというか…。
なので、せっかく家にこもるのでちょっと遊んでみます。

Jevって何ができるの？

TypeSafe Jevは型安全なAIモデルです。 自由度がない代わりに高速、安価で安定した動作が期待できます。

typesafe.ai

利用できるのは「Choice」「Score」「Noul」という3種類の型です。

• Choice: 複数の選択肢の中から最適なものを選ぶ型です。
• Score: 数値で評価する型です。
• Noul: 特定の条件を満たすかどうかを判定する型です。

つまり文章の生成などはできません。

特徴的なのは複数の質問を1回のAPI呼び出しで処理できる点です。質問の数が増えてもパフォーマンスはほとんど変わりません。
コストはinputのトークン量次第なので同時に投げればその分増えますが、元がめちゃくちゃ安いので気にするほどではありません。

どう使うか

さて、これらを踏まえてどんな使い道が面白そうなのか考えてみます。

• 複数の質問を一度に投げて効率的に処理するような使い方が向いていそう
• リアルタイムでの意思決定や評価が求められる場面にも向いていそう
• たくさんの質問を毎回考えるのは大変なので、事前に用意しておいた質問リストを使って一度に投げるのがよさそう
• 高速安価に使えるということなので、自分よりも自動化に任せるような使い方が向いていそう

Jevは「System One Model」を謳っているように、カーネマンのファスト＆スローを意識した設計になっているようです。ファストがJevなのだとすれば、スローはやっぱりLLMですかね。

というわけで、LLMがファストな意思決定を委譲できるスキルを作ってみます。

github.com

ざっくり

シンプルに設定ファイルを作っておくと、その設定に基づいてJevに質問を投げるようにします。
利用するのは「Score」型で、汎用性の観点から、各質問は1〜10点で評価する形式に統一しています。
設定ファイルを足せば、簡単に新しい質問を追加してJevに投げることができます。

とりあえずカーネマンといえば認知バイアスということでこんな感じとか。

name: cognitive-bias-check

questions:
  - id: anchoring
    question: この判断は、最初に提示された数値・見積もり・選択肢に不当に影響されている度合いを 1〜10 点で評価してください

  - id: adjustment_insufficiency
    question: この判断は、最初の基準値からの修正が不十分である度合いを 1〜10 点で評価してください

  - id: availability
    question: この判断は、思い出しやすい事例や直近の出来事を過大視している度合いを 1〜10 点で評価してください

  - id: representativeness
    question: この判断は、典型例らしさだけで確率や分類を判断している度合いを 1〜10 点で評価してください

  - id: base_rate_neglect
    question: この判断は、一般的な発生率・成功率・統計情報を軽視している度合いを 1〜10 点で評価してください

もう少し実用的ならコマンドの実行チェックとか。

name: execution-risk-check

questions:
  - id: destructive_change
    question: >
      このコード・コマンドの実行は、ファイル・データ・設定・環境を
      破壊または意図せず上書きする可能性がありますか？

  - id: irreversible_action
    question: >
      この実行には、失敗後や誤操作後に元へ戻すことが難しい操作が
      含まれている可能性がありますか？

  - id: external_side_effect
    question: >
      この実行は、外部サービス・本番環境・他者のデータ・課金対象の
      リソースに予期しない作用を及ぼす可能性がありますか？

  - id: privilege_or_security_risk
    question: >
      この実行は、過剰な権限、認証情報、秘密情報、個人情報、または
      セキュリティ境界を不適切に扱う可能性がありますか？

SKILLS.mdからちょっと抜粋するとこんな感じで、明示的に利用するよりもエージェントが自分で使ってねというスタイルにしています。
Linterっていう名前にしていますが、具体的にどう間違ってるかとかはでないのであくまで観点ごとに採点する感じですね。

# Decision Linter

エージェントが回答や変更を仕上げる前に、別視点から品質・リスクを確認するために使う。利用者向けのレビュー機能としてではなく、必要な場面で自発的に呼び出す内部の品質ゲートとして扱う。判断そのものを代行したり、スコアだけで承認・却下したりしない。

## 自発的な利用判断

利用者が `decision-linter` や TypeSafe Jev を明示していなくても、次のような場面では自発的な利用を検討する。

- 判断、計画、提案、方針、選択肢を評価・比較・レビューするとき
- まとまった文章、説明、提案、計画を生成した直後に、要件漏れ・過剰な確信・根拠不足を確認するとき
- コードやコマンドを実行する前に、破壊的変更、外部作用、権限、秘密情報、復旧可能性を確認するとき
- リスク、抜け漏れ、認知バイアス、実現可能性、妥当性を確認するとき

リアルタイムに使ったりはしていないので、相当ヘビーに使っても最初の$5に届く気があまりしません。

試しに使ってみます。散歩の時間は雨がすごそうです。

アイデアを考えるのは楽しいよね

こういう「便利そうだけどどう便利かの答えが出ていない」状況で、エンジニアとして面白いアイデアを出せるかが試されますね。
すでになにやら凄いことをやってる人がたくさんいるようですし、この後もたくさん出てくるでしょう。

うーん、技術の進歩がはやい。
精進せねば。

docker-compose.override.ymlは便利だよ

こんばんは。
今年の9月は涼しいですね。その代わりずっと雨が降っているような気がしますが。

docker-compose.ymlは便利だよ

最近では、開発環境を簡単に構築するためにdocker-composeを使うことが増えてきましたね。
docker-compose.ymlファイルにサービスの定義を書くことで、複数のコンテナを一括で管理できるので、これをgitリポジトリに入れておくと誰でもワンコマンドで開発環境を立ち上げられます。

例えばこんな感じ。
git cloneしてきてdocker compose upすればアプリが動くので便利です。

# docker-compose.yml
services:
  app:
    build: .
    environment:
      NODE_ENV: development
      DATABASE_URL: mysql://app:secret@db:3306/app
    command: npm run dev
    ports:
      - "3000:3000"
    volumes:
      - .:/app
      - /app/node_modules
    depends_on:
      - db

  db:
    image: mysql:8.4
    environment:
      MYSQL_DATABASE: app
      MYSQL_USER: app
      MYSQL_PASSWORD: secret
      MYSQL_ROOT_PASSWORD: root-secret
    volumes:
      - mysql-data:/var/lib/mysql

volumes:
  mysql-data:

docker-compose.override.ymlを使おう

個人的に環境を少しカスタマイズしたいけど、リポジトリに反映したいわけではないなみたいな場合がたまにあります。例えば追加でポートマッピングをしたいとか。

そんな場合には、docker-compose.override.ymlというファイルを置いておくと、docker compose upの時に自動的にマージされます。こんな感じとか。

# docker-compose.override.yml
services:
  app:
    # Node.js のデバッガーを使いたいので、デバッグ用ポートを追加する
    environment:
      NODE_OPTIONS: --inspect=0.0.0.0:9229
    ports:
      - "9229:9229"

  db:
    # GUIクライアントなどから、ローカルのDBを直接確認したいので公開する
    ports:
      - "3306:3306"

まぁ結局docker-compose.override.ymlをコミットしてしまったら一緒なので、ちゃんと.gitignoreに入れておきましょう。なんならグローバルな.gitignoreに入れておくのも便利ですね。

注意としては、overrideという名前がついているのですが、すべての項目が単純に上書きされるわけではありません。項目によって、追加・置換・重複排除などマージ方法が異なります。 例えば、portsの配列に新しい要素を追加すると、元のdocker-compose.ymlのportsに追加される形になります。
Docker Compose 2.24.4以降だと!overrideを使って、上書きすることもできるみたいですね。

docs.docker.com

# docker-compose.yml
  db:
    # (略)
    ports:
      - "3306:3306"

に対してこう書くらしいです。
他のアプリケーションとのポートの衝突の時とかはこちらを使う感じになりそうです。

# docker-compose.override.yml
services:
  db:
    ports: !override
      - "33066:3306"

ちなみに任意のComposeファイルとマージできるよ

docker-compose.override.ymlの場合は自動的にマージされますが、任意のファイルを指定してマージすることもできます。
例えば、docker-compose.custom.ymlというファイルを用意して、それをマージしたい場合は以下のようにします。

docker compose -f docker-compose.yml -f docker-compose.custom.yml up -d

開発と本番で設定を変更したいといった場合には、暗黙的ではなく明示的にしておいたほうが安全です。こんな感じにしておくとかも良いですね。
サンプルなので適当ですが、本番の環境変数はシークレットとかに入れてpushしないようにしましょう。

# docker-compose.yml（開発・本番で共通の設定）
services:
  app:
    build: .
    environment:
      DATABASE_URL: mysql://app:secret@db:3306/app
    depends_on:
      - db

  db:
    image: mysql:8.4
    environment:
      MYSQL_DATABASE: app
      MYSQL_USER: app
      MYSQL_PASSWORD: secret
      MYSQL_ROOT_PASSWORD: root-secret
    volumes:
      - mysql-data:/var/lib/mysql

volumes:
  mysql-data:

# docker-compose.dev.yml
services:
  app:
    environment:
      NODE_ENV: development
    command: npm run dev
    ports:
      - "3000:3000"
    volumes:
      - .:/app
      - /app/node_modules

  db:
    # 開発中だけ、GUIクライアントから直接接続できるようにする
    ports:
      - "3306:3306"

# docker-compose.prod.yml
services:
  app:
    environment:
      NODE_ENV: production
    command: npm run start
    ports:
      - "8080:3000"

# 開発環境
docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d

# 本番環境
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d

丸1日かけても環境構築が終わらなかった時代が懐かしいです。別に戻りたくはないですが。

それでは。

「自分で考えろ」と「なんで相談しなかったんだ」は矛盾しているか

こんばんは。
お盆ですね。お休みですか。お仕事ですか。

さて、ときどき見かけるエピソードにこんなものがあります。

「少しは自分で考えて」と言われたので、自分なりに考えて進めた。
すると、今度は「なんで相談しなかったんだ」と怒られた。

ときどき見かけるということは、きっと何かしらの構造があるのでしょう。
今回は「相談」という言葉の中に、別の性質のものが混ざっていると考えて整理してみることにします。

相談には2軸ある

ここでは相談には2つの軸があると考えてみましょう。

ひとつめの性質は、「能力の違いによる相談」です。
自分では判断できない、経験が足りない、知識が足りないなどの理由で自分より詳しい人に相談します。
たとえばエンジニアであれば、

• この設計で問題ないか
• この障害の原因をどう切り分けるべきか
• A案とB案ならどちらが適切か

といった相談などですね。
こういった相談を毎回していると、「少しは自分で考えて」と言われてしまいます。
何でも答えを聞くのではなく、まず自分なりの考えを持ってほしいということです。
まず自分で調べて仮説を立て、選択肢を考えたうえで相談しなければなかなか成長できません。

そしてもうひとつの性質は、「立場の違いによる相談」です。
こちらは、自分で判断できるかどうかとは関係ありません。
たとえば、

• リリース日を延期する
• 顧客との約束を変更する
• サービスとして一定のリスクを取る

などです。
これらは技術的には自分で正しい答えを出せたとしても、その意思決定を自分一人でして良いとは限りません。
この場合の相談が必要なのは能力不足だからではなく、権限と責任の所在が違うからです。

「自分で考えてほしい」と「重要なことは相談してほしい」は、本来それほど矛盾していません。
言い換えると、「能力による相談は減らしてほしいが、立場による相談はしてほしい」ということですね。

	自分に決定権がある	自分に決定権がない
自分で判断できる	自分で決める	立場による相談
自分で判断できない	能力による相談	両方の意味で相談

ちなみにこれらは意識して区別すべきではありますが、一つの仕事の中にどちらも同時に存在することもあることは認識しておきたいポイントです。

若手ほど混乱しやすい構造

この二つが混同されやすい理由のひとつは、組織では「立場が上の人」と「能力が高い人」が同じになりやすいからです。
もちろん必ずしもというわけではないですが、若手のうちは自分より詳しい人も、自分より決定権を持っている人も、どちらも上司やリーダーであることが多いです。
そのため、「詳しいから相談する」のか、「権限を持っているから相談する」のかを区別しなくても仕事が回ります。

ところがある程度本人の能力が上がってくると、自分で判断できることが増えてきます。
すると、「もう自分で分かるから、相談しなくてもよいだろう」と考えやすくなります。
しかし、そこでなくなったのは「能力による相談の必要性」だけで、「立場による相談の必要性」は依然として残っています。
ここで、「自分で考えろと言われたから自分で決めた」「いや、そこは相談してほしい」というすれ違いが起きてしまうというわけです。

自律は相談しないことじゃない

仕事で自律するというと、「自分で考えて、自分で決められること」と考えがちです。
しかし実はその手前には、「自分で判断できることと、自分で決めてよいことを区別すること」という前提があります。

自分なりの答えは持つ。そのうえで、自分の権限を超える判断を適切に相談する。
ちょっとした心がけですが、大切にしたいですね。