HomePosts

ヒューリスティックをコントロールしたい

shusann01116,15 min read

住み慣れた家、トーンダウンしたライト、歯磨きでスッキリしたあとに飲んだ水。Xをなんとなくスクロールしながらベッドに横になってうとうとしている。眠くなったのでライトを完全に消して目をつむるとなんとも言い難い不安感が込み上げてくる瞬間がある。

5 年後の自分がどうなってるのかとふと不安になり考えを巡らせるものの脳内で結論の出ない思考実験を続けて空中分解する。積み木を丁寧に積み上げる動作は私のキャリアステップの積み方にすごくマッチしている。でも、積み木の土台になっていた根幹が汎用 LLM によってとても簡単になってしまったとき、何をバリューとして訴求できるのか。

1 ヶ月後の不確実性も十分に予見できないけど。10 年後路頭に迷わない信念みたいなのは整理できると思い、このエントリーを書く。

仕事の変化

LLM もとい、いわゆる AI が起こした産業構造への影響は計りしれない。最初は IT エンジニアが職を失うと言われていたものの、今となってはその言説は下火になっている感覚がある。

2025 年 2 月にローンチされた Claude Code はそれまでの AI 支援系ツールとは一線を画す変化を与えた感覚がある。それまでは人間が主体となって IDE やエディタの延長線として座していたツールがこれを機に AI が主体となって人がガイドするという関係性に変化した。

同じ時期に Google からは Google Meet の文字起こしと要約を行う Gemini のアドオンが Google Workspace プランにロールアウトされ、それまでは課題感はありつつも実現が難しかった議事録作成の自動化が達成された。これによって誰もやりたがらなかった作業の一つがオフロードされ、本質的な議論に全員が集中する世界線が現実になった。

AI によって ◯◯ 職が仕事を失うという言説は部分的には合っているが、雇用機会の創出という観点が欠けている。 それを裏付けるのは雇用の再配置で、カスタマーサポートやコールセンターは今や AI チャットボットに多くが代替され、逆に AI を機能させるためのエンジニアリングやそれを支えるインフラの維持構築に雇用機会が発生している。過去の産業革命にも例を見るように蒸気機関が発明されれば手織り職人は機械によって代替されその職を失っているが、逆に鉄道、鉄鋼業、石炭発掘業の発達により新たな雇用が創出され経済は劇的に成長している。

何と言っても Claude Code

さて前述した通り Claude を筆頭とした AI の登場は文字通りソフトウェアエンジニアの仕事を変えた。エンジニアリングにおいて、ビジネスの言葉をコードにタイピングする作業は完全に代替されいわゆるプログラマーは時間が経つに連れ完全にその姿を消すだろう。もともとソフトウェアエンジニアは端から見ると一人で黙々と作業する印象が強かったものの、今や AI によって非同期かつ並行に実行され、エンジニアに蒸留されたのはコンテキストの投入と意思決定に対する責任を負うことに思える。

暗黙知の言語化

ソフトウェアエンジニアに残されたこのコンテキストの投入と決定責任は LLM の仕組みが関与していると考えられる。

LLM は Large Language Model の略で Wikipedia  の言葉を借りると

A large language model (LLM) is a computational model trained on a vast amount of data, designed for natural language processing tasks, especially language generation.

であり、 trained on a vast amount of data とあるように過去にあるデータから言葉を生成するモデルであると説明されている。LLM は学習時に与えられたデータと結果のセットについての傾向を知っていて、未知の入力に対して似た入力を見つけ出しアウトプットを行っている。例えば、答えや期待している結果を伝えれば比較的思った通りの結果が得られるのだが、ゴールが不明瞭だったり、コンテキストが不明瞭だったりすると指示の意図とは異なった方向性に動いてしまう。これは LLM をヘビーに活用したことがあるならば感覚的に理解できる感情だと思っており、 2026年初め時点で重要視されている、プロンプトエンジニアリングやハーネスエンジニアリングといった考え方に繋がっている。

言語化のための効率的な仕組み

LLM 登場初期からいかに我々人間が持っている背景情報 (コンテキスト) を伝えられるか観点で多くのテクニックやエコシステムが発展してきた。最初期は、期待している結果をステップごとに指示を出すことでほしい結果を導き出す プロンプトエンジニアリングが声高に語られのちにその規模を大きくした コンテキストエンジニアリング に繋がっている。次に流動的に変化する外的情報を USB の例えになぞってプラグインできる MCP が登場した。更に、何気なくやっている定型作業や仕事の型を落とし込む スキル が発明され、それら要素をレポジトリに築き上げるハーネスエンジニアリングに繋がっている。

なぜこれらテクニックが必要なのか?

とはいえ、前提としてこれらテクニックが必要で明文化しておく理由は一体どこにあったかという疑問が湧くことがある。ある程度自明かもしれないが、現代の LLM は一度学習を終わると進化しないところが根底にある。つまり、汎用的に使えるように学習されたモデルは特定の業務には特化されていない上、セッションが作り直されると過去のセッションで学んだことは蒸発してしまう。

それが故に背景情報はセッションごとに与えなくてはならず、一番最初に与えるコンテキストの正しさや設計がセッションにおけるその AI の出力を大きく左右するレバーとなってしまっている。そのため、人間であればセッションを跨いでリアルタイムで記憶しているかつ更新されているようなコンテキストやスキルがエージェントに対してはベストエフォートレベルで新鮮な状態で渡す必要があり、そのペインを緩和するために工夫がなされているのが現状なのだと考えている。

So, what ハーネス is?

OpenAI、Anthropic を初めとした基盤モデルベンダーをはじめ、Agentic Coding をどのようにしてワークさせるのか観点での知見はすでにたくさん紹介されている上、今日も明日も必ずどこかで情報がアウトプットされているくらいには活気と熱気がある。

特に Coding Agent時代の開発ワークフローについてのまとめ  は 2026 年前半時点で体系化されている実践的なベストプラクティス集であり、今日から始められることも多いと思われる。

そもそもどうして「ハーネスエンジニアリング」と呼ばれているのか、原典  によると

I…calling this “harness engineering.” It is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again.

とあり、言葉そのものは割とハイコンテクストな印象を受けた。Wordnik  における harness の定義は以下の通りである。

The gear or tackle, other than a yoke, with which a draft animal pulls a vehicle or implement. Something resembling such gear or tackle, as the arrangement of straps used to hold a parachute to the body.

どうやら体に装着する手綱といった意味が込められていそうだなと感じた。

harness image

さて、ハーネスが手綱という解釈がおおよそ尤もらしいと感じられるのは主に以下が理由である。

  1. なぜこれらテクニックが必要なのか で述べた通りエージェントに背景情報を与えることで意図を伝え正しい道を選択してもらうために人が方向性を与えている点。
  2. エージェントが間違ったことをしたら、それを次行わないようにガードする工夫を行うことが Agentic Coding をワークさせるために必要な点。

メタ認知

ここで、一歩目線を外側に向けてみる。実は上で話していた内容について、「AI」から「今日、中途入社してきた同僚」と読み替えても本質的にやることは大きく変わっていないように感じられるのではないだろうか?

AI をセッションごとに常に記憶を失い続けるニューメンバーだと思えば、そのメンバーにどのようなオンボーディングを行うのか軸でドキュメントや環境の整備を行っていくのではないだろうか。そして、そのオンボーディングが単にドメイン知識だけではなく社内のシステムへのアクセス方法や気が付かないうちに醸成されている文化をも内包していることに気がつけば、自ずとどのようにハーネスを作っていくのかアイデアが湧いてくるはずではないか?

いまは大丈夫そう

本エントリーを執筆するにあたり、種々のソースを調査した。 PdM, SWE, Designer の境界が溶けてきてソフトウェアに関わる専門職が分業してリソースを多く投入していたボトルネックが AI によって一定解消されたゆえ、それぞれのロールは互いに侵食しあい、その境目は 1 年前とは比べ物にならないくらいぼやけている。それを認知でき、ユーザー価値を創出するという極めてシンプルなゴールを見失わない限りは AI によって自分の仕事は代替されにくそうだと思えた。

ただし、それには AI のコンテキストが人間と比べて圧倒的に小さく、セッションごとに記憶が初期化されてしまうという前提条件があるが…。

AGI はまだ来ていない。その足音は着実に近づいてきた。

おわり。

ZennQiitaGitHubXRSS
2026 © shusann01116.