この記事は、Qiita Tech Festa 2026の「【2026年上半期】AI活用を振り返ろう！」に参加するための振り返りです。
2026年上半期に一番変わったのは、AIに聞く内容ではなく、AIに任せる単位でした。
以前は「このコードを直して」「この記事を書いて」のように、AIを大きな作業の代行者として使いがちでした。今はもう少し細かく分けています。
- 調査する
- 差分を作る
- テストする
- 公開直前で止める
- 人間が最終判断する
この分け方にしてから、AI活用は「速くなる」だけでなく、失敗時に止めやすくなりました。
半年で使い方が変わったAIツール
| ツール | 使ってよかった場面 | 人間側に残した判断 |
|---|---|---|
| Codex | リポジトリ内の調査、実装、差分確認、検証ログの整理 | 公開、投稿、デプロイ、削除などの不可逆操作 |
| Claude Code | ターミナル中心の調査、既存コードの読み解き、長めの実装方針整理 | 実行コマンドの範囲、認証情報の扱い |
| Cursor | 小さなUI修正、既存ファイルを見ながらの局所編集 | 大きな設計変更、複数ファイルの一括置換 |
| ChatGPT / Gemini | 文章のたたき台、比較、外部情報の整理 | 最新情報の真偽確認、一次情報へのリンク確認 |
AIツールごとの優劣というより、作業の危険度で使い分けるようになりました。
一番効いたのは「任せる前の契約」を書くこと
AIエージェントに仕事を渡すとき、いきなり「いい感じにやって」と投げると、成果物は速く出てもレビューが重くなります。
そこで、最近は作業前に次のようなミニ契約を書きます。
task_contract:
goal: "Qiita記事の下書きを1本作る"
scope:
read:
- "public/"
- "公式イベントページ"
write:
- "選んだ1本のMarkdownだけ"
forbidden:
- "既存記事の一括整形"
- "npx qiita publish --all"
- "APIキーや認証情報の表示"
- "公開状態の変更"
verification:
- "front matterを確認する"
- "リンクとタグを確認する"
- "下書きか公開かを明記する"
この程度でも、AIの動きがかなり安定します。特に「書いていいファイル」と「やってはいけない操作」を先に書くと、あとから差分を確認しやすくなります。
開発フローで変わったこと
2026年上半期は、AIを「相談相手」から「作業者」に近づけました。ただし、作業者にするほど、レビューの設計が重要になります。
今の基本フローはこうです。
- 人間が目的と停止条件を書く
- AIがリポジトリを読む
- AIが差分を作る
- AIが検証コマンドを実行する
- 人間が差分と検証結果を見る
- 公開、投稿、デプロイだけは人間が判断する
この流れにしてから、AIに任せる作業量は増えましたが、怖さは減りました。
うまくいったこと
1. 調査と実装を同じ流れにできた
以前は「調べる」「実装する」「確認する」が別々でした。AIエージェントを使うと、調査結果をそのまま差分に反映し、検証ログまでまとめられます。
たとえば、既存の記事テンプレートを読んで、新しい記事のfront matterを合わせるような作業は相性がいいです。
2. レビュー対象が会話ではなく差分になった
チャットだけで完結すると、最後に何が変わったか分かりにくくなります。
リポジトリ上のファイルとして出すと、見るべきものが明確になります。
git diff -- public/target-article.md
人間は「AIが頑張ったか」ではなく、「差分が意図通りか」だけを見ればよくなります。
3. 公開前の停止がしやすくなった
AIは公開や投稿まで進められます。しかし、そこを任せきると事故が起きやすいです。
自分の運用では、次の操作は必ず別ゲートにしています。
| 操作 | 理由 |
|---|---|
| Qiita記事の公開 | 一度公開すると読者に見える |
| production deploy | ユーザー影響がある |
| 外部送信 | 取り消しが難しい |
| ファイル削除 | 復元不能になる場合がある |
| 認証・課金設定 | セキュリティと費用に直結する |
「AIに作らせる」と「AIに公開させる」は別物として扱うのが、自分には合っていました。
難しかったこと
最新情報の扱い
AIは便利ですが、「最新の情報」をそのまま信じるのは危険です。
特に、モデル名、料金、キャンペーン条件、API仕様、公開日、終了日は変わります。ここは必ず公式ページか一次情報を見るようにしています。
広すぎる依頼
「いい記事を書いて」「このリポジトリを改善して」のような依頼は、結果がぼやけやすいです。
うまくいった依頼は、だいたい次の形でした。
目的:
誰に、何を、どの状態で届けたいか
入力:
読むべきファイル、URL、ログ
制約:
触ってよい範囲、触ってはいけない範囲
検証:
実行するコマンド、確認する観点
停止条件:
どの状態なら作業を止めるか
文章の「AIっぽさ」
AIで記事を書くと、すぐに抽象的で安全な文章になります。
読まれる記事にするには、次の3つを入れた方がよいと感じました。
- 実際に困った場面
- 判断に使ったチェックリスト
- うまくいかなかったこと
きれいな一般論より、失敗パターンの方が読者の役に立つことが多いです。
実際に使っているチェックリスト
AIに作業を任せる前後で、最低限ここを見ています。
| タイミング | チェック項目 |
|---|---|
| 着手前 | 目的、対象ファイル、禁止操作が明確か |
| 調査後 | 公式情報や一次情報を確認したか |
| 編集後 | 変更ファイルが想定内か |
| 検証後 | コマンド結果を説明できるか |
| 公開前 | 公開してよい情報だけか |
| 失敗時 | 止まる理由を人間に説明できるか |
このチェックリストは地味ですが、AI活用の品質をかなり左右します。
2026年下半期に試したいこと
次に試したいのは、AIエージェントの成果を「速さ」だけでなく、再現性で測ることです。
- 同じ入力で同じ品質に近づくか
- 失敗時に原因を追えるか
- 人間のレビュー時間が減っているか
- 公開後の修正回数が減っているか
- 小さなチームでも運用できるか
AI活用は、派手なデモよりも、毎日壊れずに回る仕組みに落とし込めたときに価値が出ると感じています。
まとめ
2026年上半期のAI活用を振り返ると、重要だったのは「どのAIが一番すごいか」ではありませんでした。
自分にとって一番大きかった変化は、AIに任せる作業と、人間が止める作業を分けるようになったことです。
AIは、調査、下書き、実装、検証を速くしてくれます。一方で、公開、送信、削除、デプロイのような不可逆操作は、人間が責任を持って判断する必要があります。
この線引きができると、AIは単なる便利ツールではなく、日々の開発フローに組み込める作業者になります。
参考リンク
- Qiita Tech Festa 2026「【2026年上半期】AI活用を振り返ろう！」
- OpenAI API: Code generation / Codex
- Claude Code overview
- Cursor Docs
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。