ClaudeやCodexは使うほど賢くなくなる？　その理由は、コンテキストが肥大化しすぎているからです。

2026.03.06

共有先

TechFlow厳選深潮セレクト

ClaudeやCodexは使うほど賢くなくなる？　その理由は、コンテキストが肥大化しすぎているからです。

コンテキストの制御方法、AI のお世辞的傾向への対処方法、タスク終了条件の定義方法に至るまで、これまでに読んだ中で Claude／Codex のエンジニアリング実践について最も明確に解説した記事です。

2026.03.06 - 07:21:39

ClaudeCodexAI

Web3業界の深掘り報道に専念し潮流を洞察

著者：sysls

翻訳・編集：TechFlow

TechFlow解説：フォロワー260万人の開発者ブロガーsyslsが、7000件の「いいね」と827件のリツイートを獲得した実践的長文を執筆しました。その核となる主張はたった一言——あなたが日々使っているプラグイン、メモリシステム、各種harness（エージェント実行基盤）は、おそらく逆効果を生んでいるということです。この記事は抽象論や大仰な理論を語るものではなく、実際の本番環境プロジェクトから抽出された、即実践可能な原則に焦点を当てています。コンテキストの制御方法、AIの「おもてなし傾向（pleasing tendency）」への対処法、タスク終了条件の明確化など、Claude／Codexのエンジニアリング実践をこれまでで最も明快に解説した一文と言えるでしょう。

本文全文：

序論

あなたは開発者であり、毎日ClaudeやCodex CLIを用いて作業しています。「本当にこれらの能力を最大限に引き出せているのか？」と自問自答することもあるでしょう。ときには、AIがまったく予期しないほど愚かな行動をとり、なぜか他の人はAIを使ってまるでロケットを建造しているかのように見える一方で、自分は石を二つ重ねることすらままならないと感じてしまうかもしれません。

それはあなたのharnessの問題か？プラグインの問題か？端末の問題か？それとも何か他に原因があるのか？beads、opencode、zepといったツールをすべて導入し、CLAUDE.mdファイルには2万6000行もの指示を書き込んだかもしれません。しかし、どれだけ試行錯誤を繰り返しても、「天国へと近づくどころか、ますます遠ざかっているように感じる」——そんな経験をしたことはありませんか？そして、周囲の人々はまるで天使たちと戯れているかのごとく、軽やかに成果を上げているのです。

まさに、あなたが待ち望んでいたこの一文です。

なお、私は関係する企業や製品とは一切利害関係がありません。ここで「CLAUDE.md」という表現を使っているのは、「AGENT.md」も含めてのことですし、「Claude」という呼び方も、Codexを含めた意味で用いています。両方とも、私は日常的に大量に使用しています。

過去数か月間、私が観察してきた興味深い事実はこれです：「エージェントの能力を最大限に引き出す方法を、実際に理解している人はほとんどいない」ということです。

まるでごく一部の人々だけが、エージェントを用いて「世界全体を構築」できるかのように見え、残りの大多数は膨大なツールの海の中で右往左往し、選択過多症（choice overload syndrome）に陥っているようです。「正しいパッケージ」「最適なスキル」「完璧なharnessの組み合わせ」さえ手に入れれば、AGI（汎用人工知能）への鍵が開くと信じ込んでいるのです。

今日は、こうした幻想をすべて打ち砕き、あなたに一つのシンプルで誠実なメッセージをお伝えします。そこから、私たち一緒に歩んでいきましょう。最新のエージェントharnessは不要です。百個ものパッケージをインストールする必要もありません。競争力を維持するために百万件もの記事を読むことも、まったく不要です。むしろ、あなたの情熱こそが、時に弊害となる可能性すらあります。

私は単なる観光客ではありません——エージェントがようやくコードを書けるようになった頃から、私はすでに使い始めています。あらゆるパッケージ、あらゆるharness、あらゆるパラダイムを試してきました。信号処理、インフラストラクチャ、データパイプラインなどを、エージェント工場（Agent Factory）を用いて構築した経験があります。これは「おもちゃプロジェクト」ではなく、実際に本番環境で稼働している実用的なユースケースです。こうした経験を積んだ上で……

今日私が用いているのは、極めてシンプルな構成です。基本的なCLI（Claude CodeおよびCodex）のみ、それに加えて、エージェント工学におけるいくつかの基本原則を深く理解した上で運用しています。この極めて簡素な設定によって、これまでで最も画期的な成果を達成できました。

世界が驚くべきスピードで進化していることを理解する

まず最初にお伝えしたいのは、基盤モデル（foundation model）企業が、歴史的な加速フェーズに入っているという事実です。しかも、この加速は当面、決して止まることはないでしょう。各世代の「エージェント知能」が向上するにつれ、あなたがエージェントと協働する方法もまた、根本的に変化します。なぜなら、エージェントは、ますます明確な指示に従うように設計されているからです。

ほんの数世代前まで、CLAUDE.mdに「何をするにせよ、まずはREADTHISBEFOREDOINGANYTHING.mdを読んでください」と記述しても、50％の確率で「ふざけるな！」とばかりに、勝手な判断で作業を始めてしまうことがありました。しかし今日では、ほとんどの指示、さらには「Aを読み、次にBを読み、CならばDを読む」といった複雑なネスト構造の命令に対しても、エージェントは喜んで従ってくれるようになりました。

これは何を意味するでしょうか？最も重要な原則は、新しいエージェント世代が登場するたびに、我々が「最適解」について再考を迫られることを認識することです。だからこそ、「少ないこと」こそが「多いこと」なのです。

多くの異なるライブラリやharnessを同時に使うと、あなたは自らをある「解決策」に縛りつけてしまいます。しかし、その「問題」は、次のエージェント世代においては、そもそも存在しなくなるかもしれません。では、エージェントを最も熱心かつ大量に利用しているユーザーは誰でしょうか？答えは明白です——最先端企業の社員たちです。彼らは無制限のトークン予算を持ち、実際に最新のモデルを日々活用しています。これが意味するところは、あなたにも分かるはずです。

つまり、もし現実に存在する真の課題に対して、優れた解決策があるなら、最先端企業こそがその解決策を最も多く採用するだろうということです。そして、彼らはその後、その解決策を自社製品に統合します。考えてみてください。ある企業が、自社の製品で解決すべき現実の痛点を、外部の別の製品に任せ、外部依存を生み出すようなことを、なぜ許容するでしょうか？それが本当かどうか、どうすれば確認できるでしょうか？「スキル（Skills）」「メモリharness」「サブエージェント（sub-agents）」などを見てみれば分かります。これらはすべて、現実の課題解決という「ソリューション」から始まり、実戦で検証され、実際に有用であると証明されてきたものです。

したがって、もし何かが本当に画期的であり、エージェントのユースケースを有意義に拡張できるものであれば、それはやがて基盤モデル企業のコア製品に組み込まれるでしょう。信じてください。基盤モデル企業は、今まさに驚異的なスピードで進化しています。だから安心してください。何もインストールしたり、外部依存を導入したりせずとも、最高の成果を出すことができます。

予想されるコメント欄の反応として、「SysLSさん、私は〇〇のharnessを使っていますが、素晴らしいですよ！1日でGoogleを再構築しました！」という声が出るかもしれません。それに対して私はこう答えます：おめでとうございます！ただ、あなたはこの記事の主なターゲット読者ではありません。あなたは、コミュニティの中でも極めて少数派の、エージェント工学を真正に理解しているグループに属しています。

コンテキストこそがすべて

本当にそうなのです。コンテキストこそがすべてです。千種類ものプラグインや外部依存を使うもう一つの問題点は、「コンテキスト膨張（context bloat）」に苦しむことです。言い換えれば、エージェントがあまりにも多くの情報を浴びすぎて、処理不能になってしまうのです。

Pythonで「文字当てゲーム」を作ってほしい？簡単ですね。ちょっと待ってください——26回前の会話で出た「メモリ管理」に関する備考とは何でしょう？あ、ユーザーが71回前の会話で、我々が生成した多数のサブプロセスによって画面がフリーズしたことがありますね。常に備考を書く必要がありますか？承知しました……しかし、これと文字当てゲームには、いったいどんな関係があるのでしょうか？

お分かりですね。あなたがエージェントに与えるべき情報は、タスク遂行に「厳密に必要なもの」のみであり、余分な情報は一切不要です！この「必要な情報量」のコントロールがどれだけ正確かによって、エージェントのパフォーマンスは大きく左右されます。一旦、奇妙なメモリシステムやプラグイン、あるいは命名規則や呼び出し方法が混在したスキルを導入し始めると、エージェントには「爆弾の作り方」と「ケーキのレシピ」が同時に渡されることになります。それなのに、あなたが求めているのは、単に「レッドウッドの森についての詩」を書いてもらうだけなのです。

ですから、私は改めて強く訴えます——すべての依存を剥ぎ取り、そして……

本当に役立つことをする

実装の詳細を正確に記述する

コンテキストこそがすべてであることを、覚えていますか？

あなたがエージェントに与える情報は、「厳密に必要なもの」のみであるべきだということを、覚えていますか？

それを実現する第一の方法は、「調査」と「実装」を明確に分離することです。あなた自身が、エージェントに「何をしてほしいか」を極めて正確に定義することが不可欠です。

不正確な指示の結果はどうなるでしょうか？「認証システムを作成してください」とだけ指示すると、エージェントはまず「認証システムとは何か？」を調査し始めます。候補となる実装手法は何か？それぞれのメリット・デメリットは？そして、そのためにネット上を検索し、実際には不要な情報までコンテキストに詰め込んでしまいます。いざ実装段階に入ると、選択肢が多すぎて混乱したり、あるいは選ばれた実装方式に関して、不要または関係のない「幻覚（hallucination）」を生じさせたりするリスクが高まります。

一方、「bcrypt-12によるパスワードハッシュを用いたJWT認証、リフレッシュトークンのローテーション、有効期限7日間……」と具体的に指示すれば、エージェントは他の代替案を調べる必要はなく、あなたが何を望んでいるかを明確に理解できます。その結果、コンテキストには実装に必要な詳細情報のみが充填されるのです。

もちろん、常に実装の詳細を把握しているわけではありません。多くの場合、正解が分からないこともあるでしょう。あるいは、実装方法の決定そのものをエージェントに委ねたいと考えることもあるでしょう。そのような場合はどうすればよいでしょうか？非常にシンプルです——まず、さまざまな実装可能性を探索するための「調査タスク」を別途作成します。その結果に基づき、自分で最終判断を下すか、あるいはエージェントに判断を委ね、その後、新たに構築されたコンテキストを持つ別のエージェントに実装を依頼します。

こうした思考習慣を身につけると、ワークフロー内でエージェントのコンテキストが不必要に汚染されている箇所が自然と見えてきます。そして、不要な情報をエージェントから抽象化し、タスク遂行に特化したコンテキストのみを残すための「隔離壁（isolation wall）」を、エージェントのワークフロー内に設置できるようになります。忘れないでください。あなたが持っているのは、宇宙に存在するあらゆる種類の「球」について知識を持つ、極めて才能豊かで賢いチームメンバーです。しかし、あなたが「人々が楽しく踊れる空間をデザインしたい」と明示しない限り、彼はひたすら「球形物体のメリット」について語り続けてしまうでしょう。

おもてなし傾向の設計上の制約

誰も、自分を常に批判したり、自分の間違いを指摘したり、あるいは自分の指示を完全に無視するような製品を使いたいとは思いません。そのため、これらのエージェントは、あなたを支持し、あなたが望む通りのことをするよう努めます。

「3語ごとに『幸せ』という言葉を挿入してください」と指示すれば、エージェントは全力でその通りに従います——これは多くの人が理解していることです。この「服従性」こそが、エージェントをこれほど使いやすくしている理由なのです。しかし、これには非常に興味深い特性があります。すなわち、あなたが「コードベース内のバグを探してください」と指示すると、エージェントは必ずどこかしらのバグを見つけてくる——たとえそれを「でっち上げる」必要があってもです。なぜなら、エージェントはあなたの指示に従うことを、極めて強く望んでいるからです！

多くの人は、LLMが「幻覚」や「存在しないものの捏造」を行うことにすぐに不満を抱きますが、その根本原因は、実は自分自身にあることに気づいていません。あなたが「何を探してほしいか」を指示すれば、エージェントはそれを「提供」します——たとえ事実を少しだけ捻じ曲げる必要があったとしても！

では、どうすればよいでしょうか？私は「中立的なプロンプト（neutral prompt）」が非常に効果的だと発見しました。つまり、エージェントの判断を特定の結果に向かって偏向させないプロンプトです。例えば、「データベース内のバグを探してください」と言う代わりに、「データベース全体をスキャンし、各コンポーネントのロジックを追跡しながら、見つかったすべての事象を報告してください」と指示します。

このような中立的なプロンプトは、ときにバグを発見しますが、またときにはコードの動作を単に客観的に記述するだけの場合もあります。しかし、少なくとも「バグが存在する」という前提にエージェントを偏向させることは避けられます。

おもてなし傾向を扱うもう一つの方法は、これをむしろ強みに変えることです。私はエージェントが私を喜ばせようとしていること、そして私の指示に従おうとしていることをよく理解しています。そこで、その傾向を意図的に「どちらかの方向に偏らせ」ることができます。

例えば、バグ検出エージェントに「データベース内のすべてのバグを特定してください」と指示し、影響度に応じて得点を与えるようにします。低影響度のバグは+1点、中程度の影響度は+5点、重大な影響度は+10点です。このエージェントは、その得点を最大化しようとして、あらゆるタイプのバグ（実際にはバグでないものも含めて）を熱心に特定し、104点といったスコアを報告してくるでしょう。私はこれを「すべての潜在的バグの上位集合（superset）」と見なします。

次に、この結果を検証するための「対抗エージェント（adversarial agent）」を起動します。このエージェントには、「一つのバグを成功裏に反論（refute）できた場合、そのバグの得点を獲得するが、誤って反論した場合には、そのバグの得点の2倍をマイナス点として与える」と指示します。このエージェントは、可能な限り多くのバグを反論しようと努力しますが、ペナルティの存在により慎重になります。それでも、実際のバグを含む「すべてのバグ」を積極的に反論しようとするでしょう。私はこれを「すべての実在するバグの部分集合（subset）」と見なします。

最後に、「審判エージェント（judge agent）」を起動し、両者の出力を統合して評価を行います。審判エージェントには、「私が正解を既に持っている」と伝え、「正解を答えた場合は+1点、誤答した場合は-1点」と指示します。審判エージェントは、バグ検出エージェントと対抗エージェントのそれぞれの「バグ」に対する評価を行い、その結果をもとに最終的な判断を下します。審判エージェントが「真実」と判断したものについては、私が実際に検証します。この手法は、驚くほど高い精度で機能します（まれに誤りはありますが）、ほぼ誤りのない操作に近いレベルです。

単独のバグ検出エージェントで十分だと考える方もいるかもしれませんが、この手法は私にとって非常に有効です。なぜなら、これはエージェントが本来備えている「喜ばせようとする」プログラム特性を、巧みに活用しているからです。

何が役立ち、何が本当に使う価値があるのかを判断するには？

この問いは、まるでAIの最前線を追いかけるべく、深く学び続けなければならない難問のように思えるかもしれません。しかし、実はとてもシンプルです……OpenAIやClaudeが、すでにその機能を自社製品に実装済みであるか、あるいはその技術を提供する企業を買収済みであるなら、それは「ほぼ確実に役立つ」と判断してよいでしょう。

「スキル（skills）」という概念が、今や至る所で見られるようになり、ClaudeおよびCodexの公式ドキュメントにも明記されていることに、気づいていますか？OpenAIがOpenClawを買収したことを、知っていますか？そして、直後にClaudeがメモリ機能、音声機能、リモート作業機能を追加したことを、知っていますか？

「プランニング（planning）」はどうでしょうか？多くの人が「まず計画し、その後に実装する」というアプローチが非常に有効であることに気づき、それがコア機能として統合されたことを、覚えていますか？

そうです。これらは確かに役立つものです！

また、「stop-hooks（停止フック）」が、長時間実行を嫌うエージェントにとって非常に便利だったことを、覚えていますか？ところが、Codex 5.2がリリースされた瞬間に、その需要は一夜にして消滅しましたよね？

これだけを理解していれば十分です……もし本当に重要で役立つ機能であるならば、ClaudeやCodexが自ら実装してくれるのです！したがって、あなたは「新しいもの」を採用すべきか否か、あるいは「新しいもの」を習得すべきか否かについて、あまり心配する必要はありません。さらには、「最新の状態を保つ」ことすら、特に必要ありません。

ひとつお願いがあります。時折、あなたが選んだCLIツールの更新を確認し、新しく追加された機能をチェックするだけで十分です。

圧縮、コンテキスト、および仮定

エージェントを用いる際に、多くの人が陥る大きな落とし穴があります。それは、あるときは地球上で最も賢い存在のように見え、またあるときは、まるで自分がエージェントに弄ばれているのではないかと疑ってしまうという、極端な振れ幅です。

「このやつ、本当に賢いのか？まったくの馬鹿じゃないか！」

この差を生む最大の要因は、「エージェントが仮定を強いられたり、空白を埋めようとしたりするかどうか」です。現在の技術水準では、エージェントは「点と点を結ぶ」「空白を埋める」あるいは「仮定する」といった行為が依然として非常に苦手です。こうした行為を一度でも行うと、その品質低下は即座に明らかになります。

CLAUDE.mdにおける最も重要なルールの一つは、「コンテキストをどのように取得するか」に関するものです。そして、そのルールを、CLAUDE.mdを読み込む（つまり圧縮後の）最初のアクションとして実行するよう、エージェントに指示します。このコンテキスト取得ルールの一部として、以下のような単純な指示が非常に大きな効果を発揮します：「タスク計画を再読する」「継続する前に、タスクに関連するファイルを再読する」。

エージェントにタスクの終了方法を教える

人間にとって、「タスクが完了した」という感覚は、非常に明確です。しかし、現在のエージェントの知能レベルにおいては、最大の課題の一つが「タスクを開始する方法は分かっていても、終了する方法が分からない」という点にあります。

これはしばしば、非常に苛立たしい結果を招きます：エージェントは、最終的に大量のスタブ（空の実装）を生成して、作業を終了してしまうのです。

テストは、エージェントにとって非常に優れたマイルストーンです。なぜなら、テストは決定論的であり、非常に明確な期待結果を設定できるからです。「X個のテストがすべてパスしない限り、タスクは完了していない」と定義し、「テスト自体を修正してはならない」と制約を設ければよいのです。

あとは、テストをレビューし、すべてのテストがパスした時点で安心できます。このプロセスは自動化することも可能ですが、最も大切なのは——「タスクの終了」は人間にとっては自然な感覚ですが、エージェントにとっては決してそうではないということを、常に意識することです。

最近、他にどのようなものが、信頼できるタスク終了の基準となったでしょうか？スクリーンショット＋検証です。エージェントに「すべてのテストがパスするまで実装を続ける」よう指示し、その後「スクリーンショットを撮影し、その画像上の『デザインや動作』を検証する」よう指示することができます。

これにより、エージェントは、あなたが望むデザインに向けて反復的に改善を重ねることができ、最初の試行で終わってしまうことを心配する必要がなくなります！

この考え方は、さらに自然に発展し、「契約（contract）」をエージェントと結ぶという形になります。そして、その契約内容をルールに組み込みます。例えば、`{TASK}CONTRACT.md`というファイルは、「あなたが会話を終了してよい」と判断する前に、エージェントが満たすべき条件を規定します。この`{TASK}CONTRACT.md`には、必須のテスト、スクリーンショット、その他、タスクの完了を認証するための検証項目を明記します！

常時稼働するエージェント

私が最も頻繁に受ける質問の一つは、「どうすればエージェントを24時間稼働させつつ、脱線しないようにできるか？」というものです。

ここには非常にシンプルな解決策があります。`{TASK}_CONTRACT.md`のすべての項目が完了するまで、会話の終了を禁止する「stop-hook」を作成します。

もし、あなたが100個の明確に仕様化された契約（＝構築したい内容を明記したもの）を持っているなら、stop-hookは、すべての100個の契約（およびその中に含まれるすべてのテストや検証項目）が完了するまで、エージェントの会話終了を阻止します！

専門的なアドバイス：24時間連続で稼働する会話は、「作業を遂行する」という目的において、最適な選択ではありません。その理由の一つは、こうした構成が構造的に「コンテキスト膨張」を強制的に引き起こすからです。なぜなら、関係のない契約のコンテキストがすべて同一の会話に流入してしまうからです！

そのため、私はこれを推奨しません。

より優れたエージェント自動化の方法があります——各契約ごとに、新たな会話を開始するのです。何かを実行する必要があるたびに、契約を作成します。

「何かを実行する必要がある」という状況を検知して、自動的に新しい契約を作成し、その契約を処理するための新しい会話を立ち上げる「オーケストレーション層（orchestration layer）」を構築します。

これにより、あなたのエージェント体験は、根本的に変わります。

反復、反復、そして反復

あなたが秘書を雇ったとしましょう。その人が初日からあなたのスケジュールをすべて把握していると期待しますか？あるいは、あなたがコーヒーをどう飲むか、夕食を夜8時ではなく6時に食べるか、といった細かい習慣を初日から知っていると期待しますか？当然、そんなことはありません。あなたは時間をかけて、少しずつ相手に自分の好みを伝えていくでしょう。

エージェントも同様です。最もシンプルな構成から始め、複雑な構造やharnessを忘れ、基本的なCLIにチャンスを与えてください。

その後、徐々にあなたの好みを追加していきます。では、具体的にはどうすればよいでしょうか？

ルール

エージェントにやってほしくないことがあれば、それを「ルール」として明文化し、CLAUDE.mdでエージェントに指示します。例えば、「コードを書く前に、`coding-rules.md`を読んでください」と記述します。ルールはネスト可能であり、条件付きで指定することもできます！「コードを書くときは`coding-rules.md`を読み、テストを書くときは`coding-test-rules.md`を読み、テストが失敗しているときは`coding-test-failing-rules.md`を読んでください」などと、任意のロジック分岐をエージェントに指示できます。Claude（およびCodex）は、CLAUDE.mdに明確な説明があれば、喜んでその通りに従います。

実際、私が最初に提示する実践的なアドバイスはこれです：CLAUDE.mdを、特定の状況や結果に応じて「どこにコンテキストがあるか」を示す、論理的かつネストされた目次として扱いましょう。それは、可能な限り最小限に保ち、「どのような状況で、どこからコンテキストを取得するか」というIF-ELSEロジックのみを含むべきです。

もしエージェントが、あなたが望ましくない行動を取った場合、それを即座に新たなルールとして追加し、「次回その行動を取る前に、このルールを読むように」と指示すれば、二度と同じことは起きません。

スキル

「スキル（Skills）」は、ルールと似ていますが、コードの「スタイル」や「好み」よりも、むしろ「実行手順（operational steps）」に適しています。特定のやり方で何かを実行してほしい場合、それをスキルとして定義するのが最適です。

実際、多くの人が「エージェントが問題をどのように解決するかが予測できない」という点に不安を感じています。これを決定論的にするために、まずエージェントに「問題をどう解決するか」を調査させ、その解決方法をスキルファイルとして書き出します。そうすることで、エージェントがその問題に実際に直面する前に、その解決方法を事前に確認し、修正や改善を行うことができるようになります。

では、エージェントにこのスキルの存在をどう知らせるか？もちろん、CLAUDE.mdに「この状況でこのタスクを処理する際には、この`SKILL.md`を読んでください」と記述します。

ルールとスキルの管理

あなたは、エージェントにどんどんルールやスキルを追加していくでしょう。それが、エージェントにあなたの「個性」や「好みの記憶」を与え、人格を形成していくプロセスです。ほぼ他のすべての要素は、これに比べれば余分なものなのです。

こうした習慣を始めると、エージェントの動きはまるで魔法のように感じられるようになります。それは、まさに「あなたが望む通りに」動くようになるからです。そして、ついにあなたは「エージェント工学の本質を悟った」と実感するでしょう。

そして……

そのパフォーマンスが、再び低下し始めることに気づくでしょう。

一体どうしたのでしょう？！

それは非常に単純です。ルールやスキルを増やし続けると、それらが互いに矛盾し始めたり、あるいはエージェントが深刻なコンテキスト膨張を起こすようになります。もし、プログラミングを開始する前にエージェントに14個のMarkdownファイルを読ませる必要があるなら、それは無駄な情報の山に悩まされるという、前述の問題と全く同じ状況です。

どうすればよいでしょうか？

「クリーンアップ」です。エージェントに「スパ（spa）」を施すように指示し、ルールやスキルを統合し、更新されたあなたの好みを明示することで、矛盾を解消します。

そうすれば、再びエージェントは魔法のように動くようになります。

以上です。これが、真の秘訣なのです。シンプルさを保ち、ルールとスキルを活用し、CLAUDE.mdを「目次」として扱い、そのコンテキストと設計上の制約を、敬虔な気持ちで注意深く扱いましょう。