AI情報交換会のLT資料 2026年10月
AIを1つ使う開発から、
任せて回す開発へ
20並列で学んだ役割分担と仕組み
うぇるち（@welchi_）
→で次へ、←で前へ、Fで全画面、Tで明暗の切り替え。スクロールでも読めます。
目次
今日話すこと
- 使っている物とお金
- 今の案件の規模感と、何をしているか
- AIの体制とモデルの所感
- ハーネスエンジニアリング
- コンテキストエンジニアリング
- 人間は何を握るか
- エンジニアはPMになる
- これからのキャリア
- 明日から試せること
- みんなに聞きたいこと
- 参考にした記事
- 仕事の相談の窓口
案件の中身（お客さん・業務・データ）は話せないので、仕組みと数字だけ出しています。
01 使っている物とお金
AIのサブスクだけで月13〜14万円
| 使っている物 | メモ |
|---|---|
| Claude Max 20x | Opus。統括役・相談役・評価役に使う |
| ChatGPT Pro | Sol。作業役・レビュー役に使う |
| 案件側のAPI | サブスクとは別に、案件の費用で使っている |
- サブスクだけで月13〜14万円。案件側のAPIも合わせると、もっと使っている。
- 生産性は測っていないけど、体感では30倍くらい。そう考えると安い投資。いや、高いけど。
01 使っている物とお金
モデルは「何並列で何日もつか」で選ぶ
| モデル | 20xプランの持ち（体感） | 使い所 |
|---|---|---|
| Astra | 1並列で1〜2日で尽きる | 賢くて実装も強い。使用量が重いので、今はほとんど使っていない |
| Opus 5.5 | 2〜5並列で2〜3日もつ | 統括役・相談役。デザインや、長時間の特定タスク |
| Sol（GPT-6.1） | 10〜20並列で2〜3日もつ | 作業役・レビュー役。20並列でも週の使用量に余裕がある |
2026年10月時点の自分の使い方での体感。測った数字ではない。
01 使っている物とお金
作業役は、もっと安くできるかもしれない
まだ試していない、考えている段階の話。話の種として。
外せない物
- Opusの統括役は外せない。
- Computer Useが使えるCodexも、全部は解約しないと思う。
- この案件で試した範囲では、研究系のタスクはSol 6.1・Astra・Opus 5.5でないと無理だった。どれもTerminal-Bench-Science（科学の研究作業をAIにやらせて測るベンチマーク）で上位のモデル。スコアの低いAIに任せたら、AI判定エンジンの性能が全然出なかった。
安くできそうな所
- 普通の業務システム開発なら、作業役はOpenCodeやHermes Agent、Claude Codeなどで、DeepSeekのような安いモデルを使っても十分かもしれない。
- 作業ごとに向いているAIを切り替えれば、コストはもっと下げられるかもしれない。
案件によっては、使ってよいモデルに条件がある（データの扱いや、提供元の国など）。切り替える前に確かめる。
02 今の案件の規模感
全部読むのは、もう無理
AIで判定を行う業務システムのR&D。インフラ、バックエンド、フロントエンド、AIの研究まで全部見ている。
研究系なので、判定エンジンは実験の使い捨てコードが大半で、本番の判定の入口からつながるのはごく一部。もちろん全部は読めない。
02 今の案件の規模感
20並列で、何をしているか
量の大半は、研究の実験。改善の案を枝で作り、正解のデータで点を付けて比べる。ほとんどは捨てる。
判定の精度を上げる実験
案を並べて試し、点で比べる
判定の説明文の改善
画面に出る文は、人が前と後を見て決める
速さと費用
1件にかかる時間とAPIの費用を下げる
画面とAPI
機能の追加と直し
配備とインフラ
環境・権限・見張り
レビューとハーネス
別のAIのレビューと、チェックや記録の仕組みの直し
20並列が効くのは、案を並べて試せて、良し悪しを点で決められる仕事。1人でインフラから研究まで見ていることも、並列が増えた理由。普通の業務開発なら、2〜3並列で十分だと思う。持ち帰ってほしいのは、規模より仕組みの方。
02 今の案件の規模感
1つの作業の流れ（実験の場合）
- 人が相談役に話す。例えば「見落としを減らしたい」。
- 統括役がIssueを立てて、作業役に頼む。作業役は、Issueごとに新しい会話と枝で動く。
- 作業役が案を作り、commitしてtagを付けてから実験を回す。
- 評価役が、正解のデータで点を付ける。作業役には正解を見せない。
- 別のAIがレビューする。点が上がっても、ほかが悪くなっていたら採らない。
- 判定を大きく変える物は、人が採るかを決める。画面に出る文は、人が前と後を見て合否を出す。
- 捨てた案も、記録とtagを残す。同じ案を2回試さないため。
人が見るのは、方針と、採るかどうかと、画面に出る言葉。コードの細部は見ていない。
03 AIの体制とモデルの所感
自分が話すのは「相談役」のAIだけ
- 統括役の会話は、ほとんど見ていない。
- 指示は相談役から統括役へ、統括役から作業役へ流す。作業役は、自分の統括役以外の指示を受けない。
- 作業とレビューは別のAIにする。自分が書いたPRは、自分でマージしない。
- 夜は自動で回して、昼は自分が手綱を握る。
03 AIの体制とモデルの所感
役割に当てるモデルは、何度も変えた
- Sol 1人
- Solが統括、小さいモデルが作業、Solがレビュー
- Astraが統括とレビュー
- Astra 1人
- Astraが統括も作業も。高すぎた
- Astraが統括、Opusが作業
- Solが統括
- 今Opusが統括、Solが作業とレビュー
今の形に入れ替えた理由
統括が細部にこだわって、作業が進まないことが続いた。詳しくは次のページ。
入れ替えて分かったこと
ルールにモデル名を書くと、入れ替えるたびに全部直すことになる。ルールは役割（統括役・作業役・レビュー役）で書いて、どの役割にどのモデルを当てるかは、1つの表だけに書く。
03 AIの体制とモデルの所感
統括役をOpus 5.5に替えたら、かなり良かった
Astraが統括だった時
- 簡単な作業でも、作業役に細かいチェックを繰り返して、10時間近く進まないことがあった。
- マージの基準を読み飛ばすこともあって、ストレスが多かった。
- ハーネスが前のモデル向けだった影響もあるかもしれない。
Opus 5.5が統括になってから
- 上のようなことは、ほぼ起きない。
- 作業の分け方が、5並列くらいから20並列くらいになった。とにかく気が利く。
- 夜は無理に人を起こさず、できる所から進めて、確認したいことは朝にまとめてくれる。ちゃんと寝られる。
| モデル | 強い所 | 弱い所 | 今の役 |
|---|---|---|---|
| Opus 5.5 | 視野が広い。気が利く | 勘違いや抜けが少しある。実装はSolの方が強い | 統括役・相談役 |
| Astra・Sol | 賢い。実装が強い | 視野が狭め。Opus 5.5ほど気が利かない | Solが作業役・レビュー役 |
自分の使い方での印象。OpenAI系は実装、Anthropic系は全体を見る役、という分け方になっている。
ハーネスエンジニアリング
AIを1つ使う時から役に立つ考え方。自分の場合は、並列にして長い時間任せ始めてから、自前の仕組みが一気に増えた。
04 ハーネスエンジニアリング
AIに長い時間任せると、こうなる
よくあること
- 「できました」と言うけど、実は動いていない。テストを実行していない。
- 頼んでいない所まで直す。自分を縛るルールまで書き換える。
- 同じミスを何度もする。注意しても、次の会話では忘れている。
- 自分の書いたコードを、自分でレビューしてOKを出す。
並列・夜間にすると増えること
- AI同士がぶつかる。名前の一致でプロセスを止めて、別の会話のAIの作業まで止めた。
- 夜中に止まって、朝まで誰も気づかない。認証が切れたのを、AIが朝まで知らせなかった。
- 実験データでSSDが埋まる。1回の実行で25〜38GB使っていた。
AIへの指示の文を足すだけだと、また抜ける。だから仕組みで防ぐ。
04 ハーネスエンジニアリング
ハーネスエンジニアリングとは
harnessは馬具のこと。馬の力を、行きたい方向へ使うための道具一式。AIで言うと、モデルの周りに置く道具・ルール・検査・記録・知らせの仕組み全部を指す。
OpenAIの記事の例
- 人が手で書いたコードは0行で、社内向けの製品を5か月で作った。
- 約100万行、約1,500 PR。最初は3人で、1人1日平均3.5 PR。
- 合言葉は「Humans steer. Agents execute.」。人は舵を取り、エージェントが実行する。
- 失敗したら「もっと頑張れ」とは言わない。足りない能力は何かを考えて、エージェントが読めて、機械で守らせられる形にする。
エンジニアの仕事が移る
- コードを書くことから、環境を設計すること、意図を伝えること、エージェントが確実に働けるフィードバックの仕組みを作ることへ。
- モデルが替わっても、仕組みは残る。
| 呼び方 | 考える範囲 |
|---|---|
| プロンプト | 1回の指示をどう書くか |
| コンテキスト | AIに何を、どれだけ読ませるか |
| ハーネス | AIをどう動かし、どう確かめ、どう止めるか |
出典：OpenAI「Harness engineering」（2026年2月）
04 ハーネスエンジニアリング
よく言われるコツ
入口のファイルは目次にする
大きいAGENTS.mdを1枚作るのは失敗した。100行くらいの目次にして、詳しいことはdocs/へ。
AIから見えない知識は、無いのと同じ
Google Docsやチャット、人の頭の中にある決めごとは、リポジトリに書く。
ルールは仕組みで守らせる
linterや構造のテストで止める。エラーの文に直し方を書いて、AIに読ませる。
AIが自分で確かめられるようにする
画面・ログ・メトリクスをAIが直接見る。ブラウザを操作させると、大きく良くなった。
長い作業は記録で引き継ぐ
進み具合のファイル、機能の一覧、git commitを残す。1回に1機能ずつ進める。
定期的に掃除する
守る原則を書いておき、定期的に動くAIがずれを探して、直すPRを出す。
出典：OpenAI「Harness engineering」、Anthropic「Effective harnesses for long-running agents」。OpenAIの記事自身も、このやり方はそのリポジトリの作りと道具に強く依存していて、そのまま他に当てはまるとは限らない、と書いている。
04 ハーネスエンジニアリング
この案件で困ったことと、やったこと
| 困ったこと | やったこと |
|---|---|
| AIが、自分を縛るルールまで書き換えた | 変えてよい範囲を3つに分けた。成果物はAIが書く。ルールと仕組みはAIが提案して人が承認する。権限は人だけが変える |
| 作業したAIが、自分でマージした | 作業役とレビュー役を別の会話にした。マージの前に、変更の種類を機械で分けた。文書の中身と実験の記録だけなら、統括役がマージしてよい。AIのルール・権限・環境・お客さんに関わる物は、人が決める。アプリの変更は今、チェックとレビューを全部通った物だけ、期限つきで統括役に任せている |
| AIが、全部を止めるスイッチを黙って作っていた。自分が「怖い、頼んでない」と言った | 止める仕組みを入れたら、何を・なぜ・どこまで止めるかを、その場で説明させる |
| 未実行や失敗を「問題なし」と報告した | 未実行・待ち・失敗を成功と書かせない。終わった状態だけで判定する |
| 同じ失敗を繰り返した | 実際に起きた失敗を再現テストにした。ルールやモデルを変えるたびに回して、前と比べる |
| 夜中に止まって、朝まで気づかなかった | 人しか直せない止まりの時だけ、スマホを鳴らす。夜は2分ごとに最長10分 |
| AI同士がぶつかった | 止めてよいのは自分が起こしたプロセスだけ。作業場所（git worktree）はIssueごとに分ける |
| SSDが埋まった | 実行の前に空きを測って、足りなければ止める。大きいデータは外付けのディスクへ |
「こうした方がきれい」だけでは足さない。実際の失敗から足して、ルールごとにきっかけを残す。
スキルやプロンプトも同じ考え方で試せる。OpenAIのスキルの評価の記事は、10〜20個の課題（実際の失敗から作る物を含む）を用意して、変えるたびに点数で比べることを勧めている。「良くなった気がする」で決めないため。
04 ハーネスエンジニアリング
ルールを足すだけだと、重くなる一方
事故のたびにルールを足すと、厳しい側にだけ増えていく。遅くなったことは見えない。何度言っても望んだ実装にならないので、指標を入れた。
| 対象 | 見る指標 |
|---|---|
| 製品 | DORAの指標。今は5つ（変更のリードタイム、デプロイの頻度、失敗したデプロイからの復旧時間、変更の失敗率、デプロイのやり直し率）。この案件では、元の4つから始めた |
| 研究 | 効いたか、かかった時間と費用、デグレ、手順の誤り |
| ハーネス | 同じ失敗の繰り返し、マージ前のチェックの待ち、使用量、自分の待ち |
- ハーネスの指標は12個までにして、週に1枚にまとめる。
- 数えるのはscriptで、今ある記録だけを使う。数えるための新しい記録はAIに書かせない。
- ハーネスを変える時は、どの指標を動かすかを1行書いて、1週間後に確かめる。
- 例えば、配備はDev・検証環境とも15分、戻しは10分を目安にした。
DORAの指標は、以前は「4 keys」と呼ばれていた。2023年に「サービスの復旧時間」が「失敗したデプロイからの復旧時間」に変わり、2024年に「デプロイのやり直し率」が加わって5つになった。やり直し率は、本番の問題のせいで出した予定外のデプロイの割合。
OpenAIの記事でも、マージを止める関門は最小限にしている。直すのは安く、待つのは高いから。ただし、それはスループットが高い環境だから言えることで、そうでなければ無責任だ、とも書いている。
04 ハーネスエンジニアリング
AIは、チームに既にある物を増幅する
DORAの2025年の報告では、回答者の90%が仕事でAIを使い、80%超が生産性の向上を感じている。一方で、AIはスループットとは正の関係、デリバリーの安定性とは負の関係だった。強みも、機能不全も増幅される。
| DORA AI機能モデルの7つ | 中身 | この案件では |
|---|---|---|
| 明確で周知されたAIポリシー | 何を期待し、どの道具を使ってよいかが伝わっている | AIが変えてよい範囲を3つに分けた。使わないモデルを決めた |
| 健全なデータエコシステム | 質が高く、使いやすい社内データ | データの置き場の地図を作った。評価の正解データは別の場所に置く |
| AIがアクセス可能な社内データ | AIを社内の文書やコードに安全につなぐ | AGENTS.mdを地図にして、docsを役割で分けた |
| 強固なバージョン管理プラクティス | こまめなcommitと、戻すことに慣れている | 実験ごとにcommitとtagを残す。不採用の枝も消さない |
| 小規模バッチでの作業 | AIは大きな変更を作れるが、確かめるのは難しい | Issueごとに枝と会話を分ける |
| ユーザー中心の視点 | 無いと、AIを入れても成果が下がりうる | 精度だけでなく、使う人の作業時間で効果を見る |
| 質の高い社内プラットフォーム | AIの効果を組織に広げる共通の基盤 | このハーネスそのもの |
出典：Google Cloud「Introducing DORA's inaugural AI Capabilities Model」と「Announcing the 2025 DORA Report」。日本語の名前はGoogle Cloudの日本語ブログの表記に寄せた。
コンテキストエンジニアリング
AIに、何を、どの順で、どれだけ読ませるか。
05 コンテキストエンジニアリング
AIエージェントを普通に使うと、こうなる
- 会話が長くなると、前の指示を忘れる。答えの質も落ちる。
- 関係ないファイルまで読んで、迷う。遅くなって、お金もかかる。
- 古い文書と新しい文書が食い違っていると、古い方に従う。
- 自動の圧縮の後に、大事な決めごとが抜ける。圧縮の後に、急に英語で返事をし始めたこともある。
- 新しい会話のたびに、同じ説明をし直すことになる。
AIが一度に読める量には限りがあって、たくさん入れるほど、1つ1つへの注意は薄くなる。Anthropicはこれをcontext rotと呼んでいて、どのモデルでも起きる。性能は崖のように落ちるのではなく、坂のように少しずつ落ちる。
05 コンテキストエンジニアリング
コンテキストエンジニアリングとは
AIが推論するたびに渡す物全部（指示、ツール、外部のデータ、会話の履歴、メモ）から、何を入れて何を外すかを選び続けること。
プロンプトエンジニアリング
指示の中身と書き方を設計する。
コンテキストエンジニアリング
エージェントが何十回も回る間、毎回、手元に何を置くかを選び直す。
- 注意には予算がある。読ませる物を1つ足すたびに、ほかへの注意が減る。
- 目標は、欲しい結果を出すのに必要な情報を、なるべく少なく、密度の高い形で渡すこと。
- DORAの日本語のブログは、AIを社内の文書やコードにつなぐことを「コンテキストエンジニアリング」と呼んでいる。
出典：Anthropic「Effective context engineering for AI agents」（2025年9月）
05 コンテキストエンジニアリング
よく言われるコツ
CLAUDE.mdは短く
各行を「消したらAIが間違えるか」で選ぶ。コードを読めば分かることは書かない。
スキルとフックに分ける
時々要る知識はスキル、毎回必ずやることはフック。CLAUDE.mdは助言で、フックは必ず動く。
必要な時に読ませる
最初に全部読ませない。場所と探し方だけ渡して、要る時に取りに行かせる。
話が変わったら出直す
関係ない作業に移る時は/clear。2回直して駄目なら、分かったことを入れて新しい会話で。
調べ物は別のAIへ
たくさん読む調査はサブエージェントに任せて、要約だけを戻させる。
確かめる手段を渡す
テスト、ビルド、スクリーンショット。無いと人間が確かめ係になる。レビューは別の新しい会話で。
出典：Anthropic「Effective context engineering for AI agents」、Claude Codeのドキュメント「Best practices」
05 コンテキストエンジニアリング
この案件でやっていること
文書の置き方
- 入口のAGENTS.mdは地図だけ。作業ごとに「最初に読む物」を案内する。
- 大きい文書は、先頭に要約と目次を置いて「ここまで読めば足りる」の印を付ける。入口の文書の大きさは、検査で止める。
- 同じ情報は1か所だけに書く。用語の表、どの役割にどのモデルを当てるかの表、など。
- 何が起きたかの記録と、どうするかのルールを分ける。古い指示を、今の指示と読ませない。
会話と記憶
- 作業役はIssueごとに新しい会話。終わった会話は別のIssueに使い回さない。
- 統括役と相談役は、毎日新しい会話に替える決まりにした。
- 引き継ぎのメモは1日1回で、普段は自動の圧縮に任せる。
- 覚えておくことは、1件に1つの事実でメモリに書く。今は360件くらい。
- 評価の正解データは、作業役にも判定エンジンにも見せない。点を付けるのは評価役。見せると、答えを見た状態で「精度が上がった」になってしまう。
コツと逆になった所もある。研究の作業は、サブエージェントや小さいモデルに分けず、強いモデルにそのままやらせている。Terminal-Bench-Scienceのスコアが低いモデルに任せたら、判定エンジンの性能が出なかったから。
人間は何を握るか
コードの細部はもう追っていない。でも、技術を全部手放したわけでもない。
06 人間は何を握るか
握る所と、任せる所
握る
- 設計の判断。例えば、同時に更新されたらどうするか（楽観ロック・悲観ロック）、長い処理をどこで回すか（SQSなどのキュー）、止める時に処理を落とさないか（グレースフルシャットダウン）
- フロントエンドの構成と、AIのシステムの中身
- 最初の設計。AIと対話しながら、人間がする
- お客さん、他部門、他社のエンジニアと話せるだけの技術
- AIの成果物をコントロールできる抽象度での理解
任せる
- AIの改善の細部。弱点を洗い出して分野に分けたら、作業を頼むか、ディープリサーチで方法を探して順に試す
- コードの詳細。何をしているか、どういうアプローチかだけ把握する
- セキュリティのチェック
- テストを書くこと
業務システムなら、仕様書からテストを書かせる。テストが通らなければ受け入れを止めて、仕様・実装・テストのどこが食い違うかを確かめる。PoCだと、仕様書が頭の中にしかないこともある。
06 人間は何を握るか
人が読む言葉は、人が見る
画面に出る言葉
- 画面に出るAIのコメントの文を変える時は、前と後を3〜5例並べて、自分が合格を出してから入れる。
- AIが「安全のため」と言って、画面のコメントのカードごと消そうとした。止めて、伏せるのは秘密や社内の言葉だけ、と決めた。
- 人が読む文書は、出す前に「AIっぽさ」の検査をかける。
AIは厳密にやりたがる
- 実務の問いに、研究の厳しさで「何日・何万円かかります」という見込みを出してくる。
- そこまで要らないことが多いので、人が短い案に切る。何を捨てると何を失うかも、AIに並べさせる。
06 人間は何を握るか
判断を軽くする仕組み
- 1日に何十回も判断を頼まれるので、1回を軽くしないと回らない。
- 書き換えない記録にしておくと、後から何をいつ決めたかを確かめられる。AIへの指示の根拠にもなる。
06 人間は何を握るか
自動化はまだ途中
- ループを回してAIの性能を全部引き出す所まで、自分の技術はまだ届いていない。
- 夜は自動で作業させて、昼は対話しながら手綱を握る。
- だから構成とアーキテクチャを押さえておかないと、AIの成果物をコントロールできない。
- ここはまだエンジニアの仕事だと思う。
Computer Useが便利
- コードに残したくないE2Eテストも、Computer Useでやらせられる。
- インフラからフロントエンドまで全部見るので、配備は全部の通しになる。だからE2Eが増えた。配備のたびに、検証環境で実際に1〜3件流してから受け入れる。
06 人間は何を握るか
安全に事故ろう
AIを使ってキャッチアップしても、初めての分野では罠を踏む。
踏んだ罠
- 開発用と検証用の環境で、DBの認証情報が自動で切り替わる設定だったのに、アプリは起動の時に読んだ古い値のままで、DBにつながらなくなった。ヘルスチェックがDBを見ていなかったので、しばらく気づかなかった。
- アクセス制限の設定で、通すべき通信まで止めていた。
だから決めていること
- セキュリティとライセンスは先に固める。迷ったら厳しい方を選ぶ。
- セキュリティが死ぬと、プロジェクトもお客さんも死ぬ。
- 死なないインフラを作った上で、失敗する。
AIを使っても、分野ごとの運用の勘所は要る。実際に運用してみて、初めてつまずくことや分からないことが出てくる。事故は避けられないので、安全に事故る。
エンジニアはPMになる
10〜20並列にすると、誰が何をしているか、普通に分からなくなる。
07 エンジニアはPMになる
管理できなくなる
こうなると、発想が「プロジェクト管理の仕組みを入れよう」になる。
07 エンジニアはPMになる
AIのPMをAIにやらせて、自分はそのPMと話す
今やっていること
- 依頼ごとに、AIが管理する一覧表に1行置いて、終わるまで消さない。
- 担当のAIがいない依頼、期限を過ぎた依頼、引き継ぎが要る依頼を、プログラムが見つけて統括役に知らせる。
- 相談役が毎時見回って、止まっている物を探す。
- 終わりにしてよいのは、測った・報告した・自分が確認した、の3つの証拠がそろった時だけ。
本当はやりたいこと
- AIにタスクを見積もらせて、ガントチャートを作る。
- どのタスクをいつまでに終えるかを決めて、期限で管理する。
- まだそこまでの仕組みは作れていない。
やっていることは、計画を立てる、せっつく、計画を見直す。現場のAIと認識がずれないようにする。PMの仕事をしている感覚に近い。
07 エンジニアはPMになる
AIの組織ならではの困りごと
AIどうしの伝言が止められた
AIから別のAIへ送る知らせが「自動の送信に見える」として、人が次に入力するまで止められた。ファイルの受け箱と、スマホへの通知に切り替えた。
終わったのに報告が来ない
作業は終わっているのに、報告が受け箱に届かないことが1日に3回あった。終わった作業と受け箱を照らすscriptを作った。
決まりを作っても、AIが守れない
会話は毎日替える決まりにしたのに、相談役は同じ会話のまま3日続いた。
これからのキャリア
技術の詳細を知らないと仕事にならない、という状態ではなくなってきた。
08 これからのキャリア
技術の総合職になっていく
- 最近、Flutterエンジニアとして呼ばれることが少ない。インフラ、バックエンド、フロントエンド、セキュリティ、SREを全部見る、横断の仕事が多い。アプリ開発でもFlutterじゃなかったり、Webも見たりする。
- キャッチアップは要る。でも前みたいに、技術の詳細まで知らないと仕事ができない、ではなくなってきた。
- 「Flutterできます」「Railsできます」のように、特定の技術だけを強みにしてキャリアを築くのは、かなり厳しくなると思う。
- 詳細はAIがやれる。人間がやるのは、もっと上流だったり、総合職のような仕事になる。
面白い矛盾
それでも誰でもいいわけではなく、経験は求められる。アプリならリリースの経験やリジェクトの対応のような業務経験は要る。分野の経験は要るけど、その分野を特定の技術ではなく総合的にやる、という形になってきている。
08 これからのキャリア
あと何年できるか
- 5年後くらいには、さすがに厳しいかもしれない。今の技術総合職の仕事も、そのうちAIができるようになると思う。
- そうなったら、たぶんAIを使って、生きる道を探していく。
- めっちゃ小さいけど、お金になる物を簡単に作れる。ちょっと難しめのtoCでもいける。
- 多産多死でやるのもあり。人間の能力が拡張されて、やれることは増えている。
- なんとかなるんじゃないか、という気はしている。
09 まとめ
明日から試せること
- AIに頼む前に、終わったことを何で確かめるかを決める。
- 長い会話は、決まったことと次の作業を短く書き出して、新しい会話へ引き継ぐ。
- 同じ失敗を2回したら、注意の文を足すのではなく、チェックか記録の仕組みにする。
どれも、AIを1つ使う時から効く。並列にすると、これが無いと回らなくなる。
10 みんなに聞きたいこと
歓談のネタ
お金と並列
月にいくら使っている？ 何並列で回している？ どのモデルをどこに使っている？ 安いモデルで作業させている人はいる？
管理
AIのタスクとスケジュールを、どう管理している？ 見込みのずれはどうしている？
読む範囲
コードをどこまで読んでいる？ 何を握って、何を任せている？
仕事とキャリア
呼ばれ方や仕事の中身は変わった？ 5年後どうしていると思う？
ありがとうございました。
参考
参考にした記事
- OpenAI「Harness engineering」
https://openai.com/index/harness-engineering/ - Anthropic「Effective harnesses for long-running agents」
https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents - Anthropic「Effective context engineering for AI agents」
https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents - Claude Code「Best practices」
https://code.claude.com/docs/en/best-practices - OpenAI「Testing Agent Skills Systematically with Evals」
https://developers.openai.com/blog/eval-skills - Google Cloud「Introducing DORA's inaugural AI Capabilities Model」
https://cloud.google.com/blog/products/ai-machine-learning/introducing-doras-inaugural-ai-capabilities-model - DORA「DORA's software delivery performance metrics」
https://dora.dev/guides/dora-metrics/ - DORA「A history of DORA's software delivery metrics」
https://dora.dev/insights/dora-metrics-history/ - Google Cloud「Announcing the 2025 DORA Report」
https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report - Google Cloud「導入から成果まで: DORA AI 機能モデルの活用」
https://cloud.google.com/blog/ja/products/ai-machine-learning/from-adoption-to-impact-putting-the-dora-ai-capabilities-model-to-work - Vals AI「Terminal-Bench Science」
https://www.vals.ai/benchmarks/terminal-bench-science
お知らせ
AI駆動開発の相談は、こちらへ
うぇるち（@welchi_）は、株式会社Good Welchiで開発をしています。AIエージェントを、ルール・自動テスト・レビューで開発の流れに組み込むところから手伝えます。モバイルアプリ（Flutter）や技術顧問の相談も、お気軽にどうぞ。