SCSKの今野です。
今回はAmazon Bedrock経由でClaude Codeを利用し、大規模エンタープライズ開発向けのコーディング用エージェントスキルを作りました。SIer技術者としての経験をどうAIに落とし込んだか、工夫点と結果をご紹介します。
自分の背景
入社して15年、システム開発を技術面から追求してきました。中でも一番好きな領域が「アプリケーション基盤（以下、AP基盤）」です。共通のフレームワークや開発規約、CI/CDパイプラインなど、大人数が同じ品質でシステムを作れるようにするための”土台”を整える仕事です。
このAP基盤を軸に、PM、PL、開発者、アプリ保守、インフラ管理・パイプライン構築まで一通り経験し、社内の技術認定制度（IPAのグレード制度を参考にした社内資格）でも、アプリケーションスペシャリスト（APS）とITスペシャリスト（AP基盤）の両方に認定されています。
PM・PLとしては仕様の曖昧さがそのまま手戻りに直結する怖さを、開発者としては人によって解釈も進め方も品質もばらつくことを、保守担当としては後から読む人への配慮の大切さを、AP基盤・インフラ担当としては環境依存のトラブルを、それぞれの立場で痛感してきました。
今回は、自分の中にあるSIer技術者としての引き出しから「AP基盤の脳」を取り出し、AIに移植した話を書きます。
エージェントスキルとは
Claude Codeには「Agent Skills（エージェントスキル）」という仕組みがあります。特定のタスクを実行するための手順・知識・テンプレートを `SKILL.md` というファイルにまとめておき、Claude Codeがそのタスクに関連する場面でだけ自動的に読み込んで使う機能です。
ポイントは、すべてを常に読み込むのではなく、タスクに応じて必要なスキルだけを都度呼び出す設計になっている点です。これにより、汎用のClaude Codeに対して、業務固有の手順書やノウハウを”後付け”できます。プログラムのライブラリのように、必要な専門知識をモジュール化して差し込めるイメージです。
今回は、この仕組みを使って「大規模エンタープライズ開発でAP基盤エンジニアが当たり前にやっている手順」を言語化し、スキルとしてClaude Codeに実行させました。
ハーネスエンジニアリングとは
「ハーネス（harness）」とは、AIモデル単体ではなく、そのモデルが安全かつ狙いどおりに動くように周囲を固める仕組み全体を指します。具体的には、どの手順で・どのタイミングで人に確認を取るか、何を自動化し何を人の判断に残すか、といった「AIの行動の型」を設計することです。
モデルの性能（＝コーディング能力そのもの）はAnthropic側の進化に委ねられますが、「そのモデルを企業の現場でどう使わせるか」は使う側の設計次第です。こうした設計判断を一連の”型”として組み上げることが、ハーネスエンジニアリングにあたります。
作ったスキルの工夫点
前提として、短納期での依頼だったため、実行するのはコーディングのみに絞っています。前後の工程まで自動化の範囲を広げるより、限られた範囲で「型」を固めることを優先しました。
そのうえで工夫したのは、大きく2つです。
1. 誰が使っても品質が底上げされる設計にする
様々な技術力・経験年数のメンバーが使うことを想定しました。個人のスキルに依存せず、誰が使っても一定水準のアウトプットになる——これはAP基盤の仕事でずっと目指してきたことと、実は同じ発想です。
2. 「不明点は想像で埋めず、必ず確認する」を徹底する
大規模なエンタープライズ開発でAIにそのままコーディングを任せると、人間の開発でもよく起きる問題と同じことが起こります。指示や仕様が曖昧なまま進めると、出来上がったものが期待とズレてしまう、というものです。少人数の開発ならズレてもすぐ直せますが、大人数が関わる開発ではその手戻りのコストが一気に跳ね上がります。
PL・PMとして、人に確認を取りながら進めることの大変さと大切さを何度も経験してきたからこそ、AIに対しても同じ原則を課すことが重要だと考えました。SIer技術者として現場で当たり前にやってきた振る舞い——仕様が曖昧なまま実装を進めず、必ず確認を取ってから手を動かす——を、そのままAIの行動原則に落とし込んでいます。
複雑な仕組みがあるわけではありません。スキルの中身は、こうしたルールをマークダウンで書いたものです。
マークダウンの例
– 不明点があれば、想像で埋めずに必ず人に確認すること
– 設計書に記載のない仕様を、推測で実装しないこと
## 手順
1. 製造に必要な資料を読み込む
2. 製造計画を立てる
（以下、プロジェクト固有のため省略）
あとはClaude Codeとチャットでやり取りするだけで、この原則が実際に機能します。
これら2つの工夫を、ハーネスとして組み上げたのが今回のスキルです。ベースになっているのは、元AP基盤エンジニアとして培ってきたSCSKの製造ノウハウです。
やっていることは、AP基盤として人向けに共通のフレームワークや開発規約を整備してきたのと変わりません。守ってもらう相手が人からAIに変わっただけです。
結果
実際に現場で開発している方々からは、人が手を入れる前提であっても第1版としての品質が高い、人が作るより早い、AIの活用を早く進めた方がよいのではないか——といった評価をいただき、現場での活用が見込まれています。
定量的な比較はしていませんが、実際に開発している人自身からこうした評価をいただけたこと自体が、裏付けになっていると考えています。この結果は、AIの性能そのものというより、どう使わせるかという設計が効いた証拠だとも感じています。
おわりに
今回作ってみて一番の収穫だったのは、AI時代でもAP基盤的な立ち位置——土台やガイドを整える役割——は必要だと分かったことでした。AIがコードを書けるようになっても、何を読ませ、どこで人に確認させ、どこまで任せるかを決めるのは人の仕事です。むしろ、開発の現場を知っている人ほど、その設計をうまく作れるはずです。
これまで積み上げてきた技術と現場での経験を役立てて、これからもSCSKにAIの風を起こしていきたいです。
今回はコーディングのみに絞ったスキルでしたが、個人としては、ハーネスエンジニアリングやループエンジニアリングをもっと活用し、設計や計画立てはもちろん、静的解析、ビルド、CI/CDパイプライン構築といったAP基盤らしい領域にも踏み込んだスキルを作ってみたいと思っています。