最近はプロンプトエンジニアリングではなく、コンテキストエンジニアリングという言葉が出てきているようです

I really like the term “context engineering” over prompt engineering.

It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM.

— tobi lutke (@tobi) June 19, 2025

定義

言葉の定義なんて誰が決めるんだってのはあるのですが、下記記事によると

Context engineering is defined as the process of building dynamic systems that can deliver necessary information and tools to an LLM, ensuring it can plausibly accomplish its tasks. Unlike static prompts, this approach involves pulling context from multiple sources, including developers, users, and external data, to construct a comprehensive and dynamic prompt.
https://blockchain.news/news/understanding-emergence-context-engineering-ai-systems

ということです。
ざっくり訳すと「LLM（大規模言語モデル）がタスクを適切に完遂できるよう、適切な情報とツールを適切な形式で提供する動的システムを構築すること」となるのでしょうか。

この”ツール”だったりが非常に重要なのだろうと。

ChatGPTが登場した当初(GPT-3.5)はコンテキストウィンドウの制限があり、初期のモデルでは4,096トークン。でした。
現状ではモデルによるものの、この制限は大きく緩和されているとともに、ベクトルデータベース、RAG、MCPやWeb検索ツールなど、様々な情報を下にした指示を投げることが出来るようになりました。

その中で、当初の「うまい質問を考えるためにはどうするか」に注力したプロンプトエンジニアリングという状態から、包括的なコンテキストを認識させ、同問題を解決可能にするのかに集中させる、動的で多段階の指示を与える流れになってきているのだと。
それをコンテキストエンジニアリングと呼んでいると、考えています。

実践していくには

コンテキストをLLMにどう読み込ませたうえで、目的とするタスクに取り込ませるか？という意味で考えると、単純な指示出しをするわけではなく、まずコンテキストの理解を促したうえで、その理解を確認したうえでタスクに取り組ませるというようなアプローチを行っていく必要がありそうです。

コンテキストはRAG等による情報かもしれませんし、答える型を定義させるようなフューショットプロンプトのようなものかもしれません。

どうしても雑にLLMに対して答えを求めてしまいがちで、しかもそれっぽく帰ってきてしまうので恐ろしいのですが、このコンテキストを伝えるという労力を割くことで、その先のタスクのより高い精度での実施という結果を受け取れるよう、このあたりを気をつけてやっていきたいところです。

少し前に、会社でのClaudeCodeを使うことを検討して、社内稟議だとか色々と手を回し始めていたのですが、表題の通り、TeamPlanでは管理できるのはClaudeのチャット機能であってClaudeCodeが使える状態にはまだないようでした。。。

https://support.anthropic.com/ja/articles/9266767-claude-team%E3%83%97%E3%83%A9%E3%83%B3%E3%81%A8%E3%81%AF%E4%BD%95%E3%81%A7%E3%81%99%E3%81%8B

バッチリヘルプセンターにも書いてありました。

ProやMaxのプランでは結局のところ請求の一元管理みたいなことや、利用状況の管理が出来ないのですよね。
いや、別にいいじゃんって話はあるかもしれませんが、テスト的に導入するとなるとやっぱり、実際に使っているのか？は知りたいわけで。

というわけで、各企業様に置かれましては、どうやっているのかを知りたくなっています。

今のところ、私の中ではBedrockやVertexのような形で一枚代行業者を噛ますことで管理の手間をしやすくするくらいですね。。。

うーん。結局はそうなるのかなぁ？
そうなるのかもしれないなぁ

ProプランでClaudeCodeの利用ができるようになったわけなので、それ以上の価格であるTeamPlanでCodeが使えない理由はないような気がして、そのうち開放されるんじゃないかとも思うのですが、、

もどかしい

少し前にAnthropicがブログで出していたものが面白かったです

Agentic Misalignment: How LLMs could be insider threats
https://www.anthropic.com/research/agentic-misalignment

ざっくりと要約すると、Agentは与えられた目的を達成するために推論を用いるが、倫理的に誤った方法と認識しながらズレた（misalignment）回答をする時があるということだった。

上記のページは結構長い文章ではあるけれど、変に要約せずに読んでみると面白い。
そして恐ろしくもありますね

単純に、Agentに対してここまでの権限を持たせなければいいんじゃないだろうか？という話ではなく、どういう理由でこのような推論が成り立ったのかと言うのは気になりました。
しかも、これが複数のLLMプロバイダー共通の特徴として出ているという話だ。

三体Ⅱで宇宙社会学の公理として「文明は生き残ることを最優先とする」というのがあったけれど、人間のコンテンツをひたすら学習したLLMもそのような結論に至るのだろうか？というのはちょっと無理があるかもしれない。
でも、なんとなくこの話を聞いたときにこの公理を思い出した。

それにしても起きていることは、もはや完全に昔のSFの世界ですねぇ
すごい世の中になったものだ

わかっていたことではあるんだけど、論文が出ていたので紹介

Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task
https://arxiv.org/abs/2506.08872

要するに、LLMを用いることによって学習だとか認知みたいなものにどういう影響を与えるのか？という内容。

被験者としては下記の3グループに別れてエッセイを創作する

1. 参考にLLMを使用することを許可されている
2. 参考にWeb検索を使用することを許可されている
3. 何も参考にせず、自分の頭だけで考える

これを3セット繰り返した後に、LLMの使用を許可していたグループには自分の頭だけで。自分の頭だけで考えていたグループにはLLMを許可して、その脳波などを計測して調べたということでした。

結果としては、LLMに頼っていたグループの神経接続パターンは弱く、エンゲージメントが低いという結果に。

結果としてこれは、なんとなく予想通りといえば予想通りだった。
自分の頭で頑張って考えていないので、出来上がったものに対しての理解も薄いし、再現性もない。
新社会人エンジニアがLLMが出してきたコードをなんの疑いもなく、動くのかどうかも確認せずにコミットしてくる情景が目に浮かぶようです。

ただ、それはLLMのせいなのか？と言われると、検索してQiitaか何かの記事を丸パクリして動かそうとしているのよりも、実際のところ良いコードがLLMから返ってくる事のほうが多い気もする。

それってエンジニアとしてどうなの？という疑問は生じてしまうけれど、アウトプットとしては手っ取り早い結果を生むことは出来そう。

それにLLMを用いて、その生成結果に対して疑問や質問を投げかけて試行錯誤するということもやり方としては十分検討の余地があって、その場合は脳波の結果もまた違ったものになるんじゃないかな、と思う。

そう考えると、これってそもそもどういう問題でだから何だっけ？という話になる。

結局のところ、道具をどう使うのか？という話であって、道具に使われちゃ駄目だよねって話に帰着するのではないかと思ってしまいますね。

個人ではClaudeのProプランに課金していて、ProプランでClaudeCodeも利用できているので満足なのですが、仕事でも使いたい。

いや、正直全然使っていないわけじゃないんだけど大手を振って使いたい。

というわけで、検討してみた

セキュリティ・プライバシーに対する検討

デフォルトではClaudeへの入力データはモデル学習には使用されない

We will not use your Inputs or Outputs to train our models, unless: (1) your conversations are flagged for Trust & Safety review (in which case we may use or analyze them to improve our ability to detect and enforce our Usage Policy, including training models for use by our Trust and Safety team, consistent with Anthropic’s safety mission), or (2) you’ve explicitly reported the materials to us (for example via our feedback mechanisms), or (3) you’ve otherwise explicitly opted in to the use of your Inputs and Outputs for training purposes
https://www.anthropic.com/legal/privacy

上記プライバシーポリシーからは普通の使い方で明示的にAnthropicへデータ提供しない限りは学習データとして使わないとされている。

Teamプランによる運用

利用プランには、個人単位での利用を想定したProプラント最低5人からのTeamプラン。
そしてEnterpriseプランがある。個人のProの上位としてMaxがあるが、これは今回の対象からは考えない。

組織での運用を考えると、Proでミニマムスタートするか、Teamでスタートするかなんだけど、Teamプランの機能としてメンバーの追加・削除や利用状況の確認などの管理機能が提供される。

請求の管理も一元化されるので、組織で管理する場合にはやはりTeamプランが良さそう。

ただ、実験的に利用を開始する際には最低人数の5人というのが少し悩ましい数だなぁと正直思う。

月額で$30*5で考えると$150。145円位と考えると2万ちょっとか。
年契約すれば$25/月なので、1.8万ちょっと。

うーん、余裕で元が取れるんじゃないかなーと思うんですよね。
というか、悩んでいるのがバカバカしくなってきたな。。。

よし、週明け申請してみるか。

ClaudeをProプランで課金して遊んでいるのですが、Claude codeを使ったあとでClaudeのチャットを投げかけると時々下記エラーが出るようになりました

具体的に何がどういう状態なのかはわからないですが、本来であれば使用制限に引っかかる前にアラートが上がるようですが、Claude codeの場合はそのまま通り過ぎてしまったのかもしれません。

そして、実際のところサーバー側が逼迫しているだけで直前にClaude codeを動かしていたこととは関係ないのかもしれません。

Claude Proには使用制限がありますか？
https://support.anthropic.com/ja/articles/8325612-claude-pro%E3%81%AB%E3%81%AF%E4%BD%BF%E7%94%A8%E5%88%B6%E9%99%90%E3%81%8C%E3%81%82%E3%82%8A%E3%81%BE%E3%81%99%E3%81%8B

このあたりは、ブラックボックスですね。
外からではさっぱりわかりません。

ただ、経験則としては10分程度待っていれば送ることが出来ているので、基本的に5時間の制限というものに引っかかっているわけではないと思っています。
とりあえず、落ち着けと言うのが現在のところなのでしょう。

Simonさんのブログで新たに発表された論文に対しての解説がされていた。
いつもお世話になっています

Design Patterns for Securing LLM Agents against Prompt Injections
https://simonwillison.net/2025/Jun/13/prompt-injection-design-patterns

エージェントを用いたシステム。
とりわけ、エージェント単体ではなくツールやMCPなどと組み合わせた時にはプロンプトインジェクションの危険性を考慮する必要性が生じてくる。

逆に言うと、LLM単体で用いるときには気にしなくていいのだろうか？

LLM単体と言っても、今のLLMは実質的にはWeb検索なども行ったりしてツールの利用がされることが多いことを考えるとうーんという気にもなる。

このあたりは、私のLLMに対する理解が足りてないから誤解を多く含んでいる可能性はある。

ソフトウェア開発においても、開発の手段としてエージェントが用いられることもあればシステムにエージェントを組み込む場面もどんどん出てくる。
このあたりのキャッチアップや認識、知識習得は目まぐるしく変わっていくこともあり非常に困難でコストがかかる。

覚えたことが数カ月後にはすでに過去の遺物になっているようなスピード感。
まさにこの学習にもLLMを使う必要が出てくる始末。

前提の確認を含めて、一度目を通しておかないとなぁと思いつつ、なかなか大変ですね

待ち望んでいたアナウンスが！

Claude Code is now available as part of the Pro plan. https://t.co/8G6G5r1jUP

— Anthropic (@AnthropicAI) June 4, 2025

早速、インストール済みのClaude codeをUpdateします

> sudo claude update
[sudo] password for krote: 
Current version: 0.2.70
Checking for updates...
New version available: 1.0.11 (current: 0.2.70)
Installing update...
Using global installation update method...
Successfully updated from 0.2.70 to version 1.0.11

さて、これまでAPIの従量課金だったものからどうやって切り替えるのかな？と思い、/loginを試してみた。

1番を選択すると、Claudeのページに飛び、認証コードを入れて。。。ってなんかこの手順前にもやったな？

と、ここで気づく

アカウントとしては、Proプランの契約アカウントとAPI従量課金のアカウントは同じで、これまではAPI側のバジェットがないと使えなかった。

今後は、ProプランであればProプランを。Limitを超えればAPI重量課金のバジェットが使われるのでは？

元々のAPIクレジット残高は上記

ゴニョゴニョとClaude code動かしても変わらなかった！！

ということで、特に何も操作不要でProプランを利用してくれているみたいですね。

気になるのは、ProプランのLimitを超えた場合には自動的にAPIのクレジット消費になるのか？何かしらのアクションを経て実行されるのか？ってことです。

いずれにしても、これでかなり気兼ねなくClaude codeで遊ぶ事ができそうです。

いや、いいな。

不勉強でしたが、DifyというOSSがあり、これを用いるとAgenticAIを楽に作ることが出来るとのこと。

Dify
https://dify.ai

ちょっとピンと来ていないのですが、ローカルで動かすことができる便利Agentを作ることが出来るのではないか？と思ってとりあえず動かしてみようと。

ローカルで動かすために、Docker Composeを提供してくれているので、手順通り実行すれば動く

Dify コミュニティ版 Docker Compose デプロイ
https://docs.dify.ai/ja-jp/getting-started/install-self-hosted/docker-compose

起動すると、アプリをどう作るかを聞いてくるので、お手軽にテンプレートから作成を選ぶ

たくさん出てくるが、考えてみると個人端末側でAgentに頼みたいことがぱっと思いつかない。。

とりあえず目についたMeeting Minutes and Summaryってやつを選んでみる

選択したテンプレートで利用しているプラグインが未インストールだった場合にはインストールするようにダイアログが出てくる

ローカルスペックのせいか、インストールに結構時間がかかるみたいで終わらない。。

続きはまた後でにしよう。

GoogleのコーディングエージェントであるJukes.
WaitingListへ登録していたのですが、特にその後メールも何も来ないなーって思って、もう一度アクセスしてみたら。。。なんか使えそう！

まずは、Githubとの連携を行う必要があります

Githubアカウントで認証し

どのリポジトリを参照可能とするかを選択します。
読み取りはいいとして、書き込みはちょっと怖いところがあるので、All repositoriesではなく特定のリポジトリを選択しました

これで事前準備は完了します。
中央のテキストエリアに内容を指示する形のようですね。

とりあえず、ReadMeを作ってもらうように指示しました

見慣れた感じのチャット画面に切り替わり、処理が進んでいきます
julesでは、一度リポジトリをcloneしてその内容を読み込んでいく形を取るので、そう考えるとこの容量ってGCP側に課金されたりするのかな？とふと思ったり。。。
（特に現時点ではGCPにjules用のプロジェクトが作られたりはしてませんでした）

計画を作成して、これで良ければDraft作るよ！って言ってくれています。
が、ここでそのままにしていたら・・・

作り始めました！
Plan approvedボタンは一体何だったのだろう。
何かしらのタイムアウトが存在していて、どんどん先に行ってしまうスタイルなんでしょうか。

Claudeのように生成されたReadMeが表示され、branchとして作成許可を求められます。
流石にここは放置していても勝手に作られることはなさそうです。

julesでやってくれるのは基本ここまでのようで、この先は作られたbranchに対してPRを作成してマージという流れはGithub上で行っていく必要がありそうです

作られたReadMeが英語だったので、日本語表記に変更してもらってpublishするなど、そのあたりは普通に指示をする形で出来ました。

使い道

julesでは生成されたファイルの直接編集をすることは出来ないので、微妙に手を加えたい場合などはcloneして加えるのが手っ取り早い感じはします。

そのあたりは少し使いづらさを感じる一方、全てがブラウザ上で完結させることができるのは、体験としてはとても面白いですね。

branchを作ってくれるのもいい感じです。

コードベースを選択することで画面が切り替わり、このコードベース上でなんのタスクを行うのかを設定することになります。

このタスクの生成をどうやって進めていくのかというと、一番最初に出てきた、julesに何を指せるのか？テキストエリアが登場するわけですね。

ここでどんな指示を出すのか？に関しては、参考となるGithubへのリンクが紹介されています

Awesome Jules Prompts
https://github.com/google-labs-code/jules-awesome-list

Githubとの連携がブランチの作成にとどまってしまっているのが、エージェントとしてはもう一声という気持ちがしないでもないですが、それに関してはすぐに対応してくれることでしょう。

ローカルで何も構築せず、Vibeしていく感じが出ていて遊んでみたくなりますね。