AIに仕事を奪われる不安から「ハーネス作成」を学ぶ理由
連載:AIに仕事を奪われる不安から始めるハーネス作成入門
全24回(週2回・12週間)|第1回 / 24この連載は、AIによるキャリア不安を持つプログラマ・SEに向けて、AIエージェントを安全に制御・検証・運用するための「ハーネス」を作る技術を、段階的に学ぶシリーズです。
はじめに:この記事で扱う不安
この記事は連載「AIに仕事を奪われる不安から始めるハーネス作成入門」の 第1回 です。
今回は、AI時代のキャリア不安を整理し、「ハーネス作成」という学習方針を紹介する テーマについて整理します。
この記事で扱う不安は、次のようなものです。
AIによって既存の実装作業や設計補助が代替され、自分の市場価値が下がるのではないか。何を学べばいいかわからない。
この不安を感じること自体は自然です。AIコーディングエージェントや生成AIの進化は、確かにプログラマやSEの作業領域に影響を与えています。
しかし、この記事では「どうすれば生き残れるか」ではなく、「今ある経験を使って、AIを業務で安全に動かす仕組みを作る側へ移れるか」という方向で整理します。
対象読者
- AIに自分の実装作業が代替されるのではないかと不安を感じているプログラマ
- 生成AI時代のキャリアに不安があるSE
- AIを「使う」だけでなく「安全に運用する基盤を作る」側へ移りたいエンジニア
結論
先に結論を書くと、AIエージェントを単体で使うのではなく、業務成果へ安全に接続するための「ハーネス」を作る技術を学ぶことが、既存のSE・プログラマ経験を活かせる方向性の一つ です。
要点は以下です。
- AIに代替される作業だけを見るのではなく、AIを制御・検証・運用する領域を見る
- SE・プログラマが持つ設計・テスト・運用の経験は、AIハーネス設計で再利用できる
- 小さなハーネスから始め、Qiita記事とGitHub成果物として学習過程を可視化する
なぜこのテーマが必要なのか
生成AIやAIコーディングエージェントの進化によって、コード生成、設計書ドラフト作成、テストコード生成など、これまでプログラマやSEが担ってきた作業の一部がAIに委任可能になりつつあります。
この変化を見て、「自分の仕事がなくなるのではないか」と感じるのは自然な反応です。
しかし、AIを業務で使おうとすると、以下のような課題が出てきます。
- AIの出力が正しいかどうかの検証が必要
- 機密情報をどのLLMに渡してよいかの判断が必要
- AIの作業結果を誰が承認するかの設計が必要
- 複数のAIエージェントやツールを連携させる仕組みが必要
- 障害が起きたときの再現・原因調査のためのログ設計が必要
これらは、AIを「使う」だけでは解決できません。AIを「業務で安全に動かすための基盤」を設計・構築する人が必要です。
この基盤を、この連載では「ハーネス」と呼びます。
ハーネス作成という選択肢
ハーネスとは何か
「ハーネス」とは、もともとテスト駆動開発における「テストハーネス」や、電気配線における「ワイヤーハーネス」から来ている概念です。
この連載での「AIハーネス」は、以下を統合する制御・運用基盤を指します。
- AIエージェント: タスクを実行する存在
- MCPサーバー: AIに渡す道具箱(ツール群)
- Knowledge / RAG: AIが参照する知識基盤
- ログ / 監査: 実行結果を記録し、再現可能にする
- Human-in-the-loop: 重要な判断で人間が承認する仕組み
- 入出力契約: AIへの指示と結果を構造化する
AI単体利用とハーネス運用の違い
| 観点 | AI単体利用 | ハーネス運用 |
|---|---|---|
| AIへの指示 | 自然言語プロンプト | 構造化されたtask_request |
| 結果の検証 | 人間が目視確認 | 品質ゲート・自動チェック |
| 知識の管理 | プロンプトに都度記述 | Knowledge MCPで一元管理 |
| ログ | なし、または手動メモ | 実行ログを自動記録 |
| 承認 | なし | Human-in-the-loopで制御 |
| 再現性 | 低い | task_request + ログで高い |
既存のSE / プログラマ経験をどう活かせるか
AI時代に新しい技術を一から学ばなければならないと思うかもしれませんが、ハーネス設計に必要な考え方の多くは、SE・プログラマが実務で身につけているものです。
| 既存経験 | ハーネス作成での活かし方 |
|---|---|
| 要件定義・業務分解 | AIエージェントへのtask_request設計 |
| テスト設計・品質保証 | AIの出力検証・品質ゲート設計 |
| ログ設計・障害調査 | AI実行ログの設計・再現性確保 |
| API設計・インターフェース設計 | MCPサーバーのツール分割・入出力契約 |
| 運用設計・保守 | Human-in-the-loop・監査設計 |
| セキュリティ・権限管理 | 機密情報のマスキング・モデル選択 |
実務経験を持つ人ほど、「AIが何をすべきか」だけでなく、「AIが間違えたとき、止まったとき、危険なとき、どうするか」を設計できます。
全体像
この図は連載全体を通じて拡張していく予定です。今回は全体像の把握に集中します。
小さく始める具体例
不安整理表
まず、自分の不安を整理してみましょう。以下のような表を作ることが、最初のアクションになります。
| 不安 | 記事で扱う変換先 |
|---|---|
| AIにコード生成を奪われる | コードを書く力を、AIに指示・検証・統合する力へ拡張する |
| 設計書作成もAIに置き換わる | 設計経験を、AIエージェントの入出力契約・品質基準設計に転用する |
| 若手やAIツールに負ける | 実務経験者ほど業務分解・例外処理・監査設計で優位性がある |
| 何を学べばよいかわからない | ハーネス作成を12週間の段階的学習ロードマップとして示す |
| 副業や転職に使える成果物がない | Qiita連載とGitHubリポジトリをポートフォリオ化する |
最小のtask_request JSON例
AIエージェントに仕事を任せるとき、自然言語だけではなく構造化された「契約」を使います。以下は最小のtask_requestの例です。
{
"task_request": {
"task_id": "example_001",
"task_type": "generate_document",
"input": {
"theme": "AI時代のSE経験の再利用",
"format": "markdown",
"constraints": ["2000字以内", "図を1つ含める"]
},
"quality_gate": {
"min_score": 4,
"required_checks": ["technical_accuracy", "readability"]
}
}
}
このJSONは最小例であり、実際にはログ出力先、承認フロー、使用モデルの指定などが追加されます。この連載では、回を追うごとにtask_requestを拡張していきます。
実装・設計時の注意点
| 注意点 | 理由 | 対策 |
|---|---|---|
| AIの出力を無条件に信頼しない | 生成AIはハルシネーション(幻覚)を起こすことがある | 品質ゲートと人間レビューを組み合わせる |
| 機密情報を外部LLMに送らない | 業務データや個人情報の漏洩リスクがある | ローカルLLMの活用やマスキング設計を行う |
| 一度に全部作ろうとしない | 学習効率が下がり、挫折しやすい | 最小構成から始め、1つずつ機能を追加する |
今回の小さな成果物
- 自分の不安を3つ以上書き出し、「変換先」を1つずつ考える
- 上のMermaid図を自分のGitHub READMEに貼ってみる
- task_requestのJSONを自分用に1つ書き換えてみる
まとめ
この記事では、AI時代のキャリア不安を整理し、「ハーネス作成」という学習方針について整理しました。
重要なのは、AIに代替される作業だけを見るのではなく、AIを安全に・再現性高く・業務成果へ接続する仕組みを作る技術に目を向けること です。
SE・プログラマとしての実務経験は、ハーネス設計において大きな資産です。要件定義、テスト設計、ログ設計、運用設計といった経験は、AIハーネスの中核を担います。
次回予告
第2回:最小構成のAIハーネスをMermaidで設計してみる(金曜日公開予定)
次回は、今回紹介したハーネスの全体像をさらに分解し、最小構成のAIハーネスをMermaid図で具体的に設計する テーマを扱います。
次回扱う内容:
- 全体像から「最小で動くハーネス」を切り出す考え方
- AIエージェント・MCPサーバー・task_request / task_resultの3点セットで最小構成を作る
- Mermaid図で構成を可視化し、GitHubのREADMEに貼れる形にする
- 最小構成に含めるもの・含めないものの判断基準
次回の成果物:
- Mermaid構成図(最小AIハーネスのアーキテクチャ図)
次回までに試しておくと良いこと:
- 今回の全体像Mermaid図を自分のリポジトリに貼ってみる
- 「自分の業務でAIに任せたい作業」を1つだけ考えておく
連載目次
| 回 | タイトル | 状態 |
|---|---|---|
| 1 | AIに仕事を奪われる不安から「ハーネス作成」を学ぶ理由(この記事) | 📖 |
| 2 | 最小構成のAIハーネスをMermaidで設計してみる | 次回 |
| 3 | AIにコードを書かせるだけでは足りない理由 | ─ |
| 4 | task_request / task_resultでAIエージェントの仕事を契約化する | ─ |
| 5 | SEの設計経験をAIエージェント制御に転用する | ─ |
| 6 | ハーネス用のディレクトリ構成とREADMEを作る | ─ |
| ... | 全24回の連載を予定しています | ─ |
連載情報
- 連載名:AIに仕事を奪われる不安から始めるハーネス作成入門
- 全24回(12週間・週2回)
- 投稿曜日:火曜日(キャリア・設計・概念)/ 金曜日(実装・検証・テンプレート)