Sabitlenmiş Tweet
この表紙、めちゃくちゃこだわりました
ミケランジェロの「アダムの創造」-- 神がアダムに知恵を与える瞬間。これをContext Engineeringの表紙にしたかった
AIに正しいコンテキストを渡す行為は、まさにこの構図そのもの。方向性を決めるのは、常に人間の側です
[画像]
amzn.asia/d/0dNeVFvn
日本語
井本賢 | kenimo49
312 posts
井本賢 | kenimo49
@kenimo49
WebRTC×音声AIエンジニア | コンテキストエンジニアリング実践者 | Kindle「実践Claude Code」「LLMO」著者 | Qiita 67,000PV
Japan Katılım Şubat 2026
38 Takip Edilen36 Takipçiler
"Trust, but verify"（信頼せよ、されど検証せよ）
レーガンがゴルバチョフとの軍縮交渉で繰り返した言葉。相手を
信頼する姿勢と、検証の仕組みは矛盾しない。
LLMとの協業もこれと同じ。モデルを信頼してコードを書かせる
。でもハーネスには必ずレビュー機構と改善ループを組み込む。
LLM-as-a-Judgeも、judgeが正しい保証はどこにもない。
モデルが優秀になるほど「まあ大丈夫でしょ」と検証を省きたく
なる。核兵器と同じで、信頼が深まった時こそ検証の仕組みが要
る。
日本語
ハーネスエンジニアリングがまさにこれ。
「来年のモデルならCLAUDE.mdなんて要らなくなるよ」——かもし
れない。でも今日出荷するコードは今日のモデルで書く。
ゲーム開発者がCPU世代ごとの最適化で"計算機の考え方"を体得
したように、ハーネスを書く過程で得る「AIに何をどう渡せば動
くか」の勘所は、モデルが賢くなっても残る。というか賢くなる
ほど効く。
にゃほ@Temp002a
@mizchi CPUの性能が伸びていたときのゲーム開発にたとえ、「例え来年には不要になるチューニングでも、今のために開発していた」のと同じという話をみました
日本語
井本賢 | kenimo49 retweetledi
1年目の時、コードレビューでDDDのRepository設計がボコボコにされた話。
僕のコード
・users → UserRepository
・orders → OrderRepository
・order_items → OrderItemRepository
先輩「テーブルごとにRepository作るのはアンチパターン。Repositoryは集約単位で作るもの」
集約 = 整合性を保つオブジェクト群
テーブルごとにRepository作ってる人は要注意。
日本語
既に一定のタスクはQwenやGamma4で割り振っているので、ハーネスやコンテキストをちゃんと設定するひとと、あとはそれを使う人で分けるとかは可能かと！
きしだൠ(K1S)@kis
たとえばエンジニア全員に1万円のコーディングプランを割り当てるとして、2年で24万円。 それなら24万円高いPCを配ってローカルLLMでやらせればいいのでは、ってなる閾値が来ると思う。
日本語
WebRTCベースの音声AIフレームワーク「LiveKit Agents」、実務で触ってみると完成度高い。Ollama+Pipecatとの統合でローカルLLM音声対話がサクッと動く。リアルタイム通信の低遅延とLLMの推論を組み合わせるアーキテクチャ、ロボット開発やってた頃のPepperの音声認識と比べると隔世の感がある。
github.com/livekit/agents
#VoiceAI #WebRTC
日本語
新しいPJが始まるので今回のPJでは
仕様駆動の仕組みとe2etestを構築して、レビューを3層構造にして
LLM as a judgeと human in the loopのどちらの仕組みもとりいれてやろう
日本語
AIエージェント25体を仮想の町に住まわせたら、
誰も指示していないのにバレンタインパーティが自然発生した。
Stanford大学の論文「Generative Agents」の話。
記憶・反省・計画の3層を与えるだけで、社会的行動が生まれる。
消費財や投資のマーケティングシミュレーションに使えないか、今検証中です。
日本語
「LLMとばかり話していると対人スキルが落ちる」と言われるけど、逆だった。
LLMに毎日ダメ出しされて覚えた型が人間相手にも効く。
鍛えられたのは私のほうだった。
日本語
直列実行のハーネスと並列実行のハーネス設計はできることや、オーケストレーション機能でのどこまで使えるかも別なので、直列作ったらそのまま動くという実装方針はかなり手戻りが多くなります
日本語
みんな勉強や努力という言葉を「そう思っている時点で負け」など言ってますが、
そもそも仕事上でも求められる勉強量の多いエンジニアという職業にとって
仕事に関係ない勉強も努力も十分、贅沢な趣味なので
頑張ってやろうとしている時点で、十分努力の才能があると思います。
日本語
井本賢 | kenimo49 retweetledi
売り上げを上げて、
ROIが立つようになったら、エンジニアを雇って整備する
それまではセキュリティリスクを抱えながら走るというのも経営判断としては全然ありだと思います。
可能であるなら技術者倫理に従って、人を傷つけてしまう。そういう状況は避けてほしい。
Kinopee@kinopee_ai
個人が、バイブコーディングで作ってリリースするようなサービス、プロダクトは細かいことは気にしないのもアリ。問題があったら対処療法。それよりも、素早くフィードバックループを回す。これも立派な戦略。
日本語
デリバリーの鉄則：最終アウトプットの品質は、プロセスの
最弱ステップで頭打ちになる。どれだけ後工程を磨いても、
ボトルネックの下限を超えられない。
LLMでも同じでした。Sonnet 4がどれだけ賢くても、
コンテキストが薄ければ出力は嘘になる。
Saito@Hakky@hakky_kazumasa
イーロン・マスクに「なぜ他社よりスピードが速いのか」と聞いた人がいます。 答えが面白かった。 「私は常に"制約要因"に集中しています。資本がボトルネックなら資本の問題を解く。別の何かがボトルネックなら、そっちを解く。それだけです。」 そして、こう続けました。 「うまく回っているところには、私はほとんど顔を出しません。でもボトルネックがある場所には、頻繁に現れます。」 得意なことではなく、楽しいことでもなく、今チームの足を引っ張っているものに全集中する。 これがマスクの時間の使い方。 ほとんどのリーダーは逆をやってしまいます。居心地のいい仕事に引き寄せられ、難しい問題を後回しにする。 自分も気をつけないといけないと思った話。
日本語
PMやPJMは
プロジェクトをうまく進めるための計画や手札を用意するのはもちろんなんですが、
結局最後は
みんなから好かれて、この人のためならちょっとは頑張ろうかなと思わせる状況を作ることも大事だと思います
わんこPM@dx_saru
エンジニアのときは「考え方」や「伝え方」で悩むことはほとんどなかった。でもPMになってから、ここでずっと悩んでいる。 エンジニアは正解が比較的明確だし、思考が内向きで成立するし、ある程度の共通言語があるから伝えやすい。 でもPMだと、正解を作りにいかないといけないし、 思考が外向きで人によって前提が違ったり、同じ内容でも伝え方で合意が変わる。 しかも、教科書的な知識をつけただけじゃ太刀打ちできないのよね。小さく試して、反省してを繰り返して身につけていくしかない
日本語
なんと！今使ている文字お越しよりも精度が高いかも！また、私のAIの力がつよくなる！
えいと@7_eito_7
マイクロソフトが「音声→文字起こしAI」を無料公開。 すでにGitHubで⭐3.8万。 ・会議の音声 → 自動で議事録化 ・誰が話したかも識別 ・しかも60分を一発処理 その名も「VibeVoice」👇
日本語
ハーネスエンジニアリングをしっかり学んで、
構築するとRAGと同様でClaude Opusとhaikueでほぼ同じ結果がでたのはなかなか感動しました
日本語
これが真実かもしれない。
openAI, anthropic, langcahinすべて違うし、みんなのこう出会ってほしいハーネスエンジニアリングの形も違う。
私はマーケティング、未来予測までするプロダクトの構築というものがハーネスエンジニアリングだ
さて@public_sate
ハーネスエンジニアリング 理想の開発(ないしは運用)スタイルを掲げて、それを実現させるエンジニアリングだ
日本語
井本賢 | kenimo49 retweetledi
最近「Claude Codeが前より雑になった」と感じていたんですが、この投稿を見て原因と対策がわかりました。
Claude Codeには内部的に「思考予算（thinking budget）」があり、回答前にどれだけ深く考えるかを制御しているんですが、最近のアプデでそのデフォルトが「medium」に変更されたそうです。
その結果：
- 単純なタスク → 問題なし
- 複雑なタスク → 十分に調査せずにいきなり編集に飛びつく傾向が出る
これが「Claudeがバカになった」と感じられる原因だと。
▼3つの対策
-----------------
1. /effort high — 思考予算を上げる（難しいタスクの前に実行）
2. showThinkingSummaries: true — 思考過程を可視化して、浅い思考に気づけるようにする
3. CLAUDE.mdにルールを書く
「読んでいないコードは変更するな」と明示的に指示
-----------------
僕の場合はトークンにまだ余裕があったので、settings.json に “effortLevel”: “high” を追加してデフォルト設定にしました。
まだこの設定にしたばかりですが、体感は以前のようにちゃんと文脈を汲んでくれる感覚が戻った気がします。
同じように「最近ちょっと雑になったな」と感じている方は、ぜひ試してみてください。
Paweł Huryn@PawelHuryn
So, I did some research. The regression is real. But it's not Claude getting dumber. And you can fix that. Thinking budgets were adjusted. For complex multi-file work, the default medium effort may not be enough. Three fixes: 1. /effort high (or /effort max on Opus for hard debugging) 2. ~/.claude/settings.json → "showThinkingSummaries": true 3. CLAUDE.md: "Research the codebase before editing. Never change code you haven't read." GitHub issue #42796 analyzed 17,871 thinking blocks across 6,852 sessions. The pattern: when thinking depth drops, the model shifts from research-first to edit-first. Claude didn't get worse. The defaults got conservative.
日本語