採用サイトを公開したあと、どこを改善すべきかを客観的に判断するのは簡単ではありません。
株式会社ベイジ代表取締役の枌谷力氏は、採用サイトを約200項目で診断するツールをClaude Codeで自ら内製し、無料公開しました。エンジニアという肩書きで活動したことはない、という立場からです。
2026年7月9日、Offersのウェビナーに枌谷氏が登壇しました。テーマは「Claude Codeで内製した、約200項目の採用サイト診断ツールの裏側」です。
本記事では、枌谷氏が語った開発の設計思想と実践知を、弊社代表 鈴木裕斗との質疑応答も含めてお届けします。
「効率化」ではなく「サービス向上」の文脈でAIを使う
枌谷様：そもそもの問題意識として、AI活用は効率化の話をすることが多い気がするんですよね。「これだけ時間が半分に減った」とか「こういうことをやっていた人がいなくなった」とか。
もちろんそれはそれで大事です。ただ、そもそも自分の会社の力を向上させたり、サービスの質を向上させたりする分野で使った方が、AIは重要だったり、使うことが楽しかったりするんじゃないかな、と。
業務効率化ではなく、サービス向上の文脈で何か作れないか。 それがずっと考えてきたことです。その中の1つが、今回の診断ツールになっております。
元になったのは、公開済みの162項目のチェックリスト
ちょうどいいなと思ったのは、我々が採用というものを、割とデータを集めて活用しているという側面があったところです。
当社は自然な自社の採用の応募だけで200人ぐらいいたりします。50人弱の会社としては結構多い方だと思うんですが、「こういうことをすれば人が集まってくるのか」というのが、ある程度自社の肌感覚としてあるところ。
それから採用の専門家として活動して、専門家の方と情報交換をさせていただいたことがあるところ。あと結構力を入れているのが、市場調査を月1ぐらいで定期的にやっているところです。
こういったデータの元の素材があるというのが、AIを使った診断サービスには非常に合っているなと思いました。
それから、ナレッジをなるべく体系化して再利用できるようにしようという文化が社内にあります。実際に採用サイトチェックリストというものも2025年に公開していて、これをベースにすれば診断ツールがすぐ作れるんじゃないか。それが元々の発想でした。
なので、これから診断ツールを作ろうという会社さんの条件として加わると思うのが、こういった言語化や体系化が元々あるのか、そのベースになるデータが溜まっているのか、というところです。
溜まっていないならないで、それもAIに作ってもらうというのはあります。ただ、最初のハードルの高い低いは変わってくるかなという気がしますね。
非エンジニアが作った、約200項目の採用サイト診断ツール
枌谷様：まず、どんな背景の人間かを軽くご説明しておいた方が分かりやすいと思います。
私は株式会社ベイジという、世間的に言うと制作会社の代表をやっている者です。Webデザイナーであった時代は結構長く、コーディングやJavaScriptを書いたりもしていました。ただ、エンジニアという肩書きで活動したことはないという立場です。
元々新卒はNTTデータだったので、ずっとITの世界にいたという意味では多少は分かっているんですが、実際にコードを書くところは素人に近いようなものかなと思っております。
会社としては、BtoB企業の成長を支援するというところで、マーケティング・採用・業務改善の3軸から支援しています。きっちりWebサイトという形になっているもので300社以上、ご相談レベルで言うと400社近くあるんじゃないかなというところです。
URLを入れると、約200項目で採点される
インターフェイス自体はすごくシンプルで、URLを入れて必要事項を入れていくと、裏側で仕組みが回って診断をしてくれます。
これは実は単純な診断サービスではなく、リード生成の機能を持たせています。社名と名前と連絡先を入れていただくと、それがリードジェネレーションになる形です。
最近BtoBだとホワイトペーパーの効力が下がっているという話があって、我々もそれに対処するソリューションが何かないかなと。その中にこの診断ツールがあるんじゃないか、というBtoBの実験みたいな性質も少しあったりします。
フロント側で見える以外に、バックエンドも存在しております。管理画面があって、今まで診断したデータが全部溜まっている感じですね。
どの企業がどういう診断をして何点ぐらいだったかも全部記録として残るので、これ自身が採用サイトをご提案する上での1つのデータベースになっています。
それから、一定期間、1ヶ月で公開が停止するんですが、公開を復帰させる機能も付けました。お客様から「過去に見たけど、もう見れなくなっている」という要望があった時に、すぐ復活させられるようにしています。
単純な診断以外に、マーケティングとセールス全般、あるいは実際に支援した時のコンサルティングにも使える。そういう複数の役割を持たせているものになっております。
Figmaを一切使わずに作った
余談ですけど、Webサイトを作るのは、普通は今までFigmaを立ち上げてデザインを作って、そこからコーディングをするというのが一般的な流れだったと思います。
今回のツールはFigmaを一切使っていないですね。いきなり作り始めています。
画像もChatGPTで画像生成だけさせて、それをClaude Codeに渡して組み込むというのをやっているんですが、デザインの指示は全部Claude Code上からやっています。全くデザインツールを使わずにデザインしているというのが1つの特徴かなというところです。
なお一点だけご注意なんですが、これはかなり負荷が高い仕組みになっていて、AWS側の制約もあるので、同時に診断可能な件数を2件に制約しております。一時的に集中するとお待ちいただくことが発生します。
開発プロセス：仕様検討に時間をかけ、実作業は12時間
枌谷様：基本のプロセスは、そんなに変わったものではありません。まず最初に仕様を検討します。いきなり作らせるんではなくて、仕様検討には割とそれなりの時間を使っております。
仕様に合わせてフォルダー設計。フォルダー設計自体はAIに相談してやっています。データをちゃんと格納した上でプロンプトを作る。ここもAIに頼んでやってもらっています。
一旦プロンプト作りまでやった上で、やっとClaude Codeで開発という感じです。いきなりClaude Codeで開発したというよりは、前段の仕様検討に入念に力を入れているところがあります。
しっかり仕様検討したとしても、作ってからのフィードバックによる改善が結構大事です。実際に使った時間は12時間ぐらいだと思うんですが、日数で言うと断片化しているので、3日ぐらいはかけて磨き上げをやっていますね。
工程はポンと出てきたというものではなく、それなりに手間暇かけないと、少なくとも今の技術ではそんなに簡単にいいものはできません。逆に言うと、こういうことをエンジニアでない人もできるようになっているというのが今の時代のすごさかなという気がします。
最初のプロンプトは「質問してください」から始める
最初の始まりのプロンプトは、実はめちゃくちゃシンプルです。
いろんなツールを開発する中で溜まったノウハウなんですが、自分自身が明確に仕様を考えられることってやっぱり少なくて、どっちかというとそれはAIに頼った方がいいかなと思ってます。
ただ「こういうのが作りたい」というのを自分起点で発信した方が、より精度は高くなります。なので自分の考えは一応最初に送るんですが、あんまり具体的に考えていないなら、むしろ質問させる。質問に答えながら仕様を詰めていくプロセスを取った方がうまくやれるなと。
大体最初のプロンプトは「この質問をしながらステップを進めてください」みたいな形で始まります。別のツールも大体こうやって、質問をさせながら自分でそれに答えて仕様を詰めるという形で作りました。
AIが出した仕様に、自分の要望を言語化してぶつける
チャットのClaudeに「自分に質問してください」と投げかけると、質問を向こうがしてくれます。「この診断のターゲットは」「提供形態はどんなイメージか」「診断結果のゴールは」といった具合です。
これにどんどん答えていくと、勝手に仕様が固まっていきます。そうすると仕様書みたいなものを作ってくれるんですよね。
これをそのまま渡して開発させることもできるんですが、もう少し深掘りしたいということで、深掘りする質問を送らせて、結構やり取りをずっとしている感じです。
それを見た上で、私の方で「こんな仕様にしたい」というアイデアをまた投げかけます。
考えてもらうだけだと、やっぱり完全に自分の思い通りにはなりません。AIが出してきたものに対して「私はこう考えている」「私はこういうことがしたい」という要望も、ちゃんと言語化して伝えるというのをやっていきます。
AIに作ってもらうというよりは、共作しているような感じですよね。このやり取りを延々とやっていくと仕様書がバージョンアップされていって、もうバージョン3までできてきました。
最終的にまとまったなというところでプロンプト化してもらい、それをClaude Codeに渡して開発するという流れです。
チャットのClaudeとClaude Codeを使い分ける
枌谷様：前提として、多くの人が使っているのはチャットのClaudeだと思うんですよね。「開発ができるぞ」「もっと複雑な使い方ができるぞ」とみんなが注目しているのがClaude Codeです。
モデルは一緒なんですね。 裏で使っているモデルは、最新モデルだとFableが出てきていますが、全部使えるという形になります。
なので究極、Claude Codeで全部賄えるんですけれども、私は実は使い分けをしております。
チャットは1対1での対話。エージェントは一気通貫で開発をさせられる。モデルは一緒だけどここの動きが違うので、仕事の任せ方が変わるというのが大きな特徴です。私は全部エージェントでやらせるんじゃなくて、チャットとの対話を結構大事にしています。
具体的には、相談とアイデア出しとプロンプト化はチャット。開発に入ってからがClaude Codeという形で使い分けております。
エンジニアの方は、AIエージェント上で全部やってらっしゃる方の方が使い慣れているかもしれません。
ただ、私のようなどちらかというとビジネスパーソン側にいる人は、2つがごちゃ混ぜになっているより、相談はClaude、開発はClaude Codeと分けた方が、頭の整理もできるし、コンテキストも追いやすい。だからこういう使い方をしています。
診断結果の読み方と、AIにまだ分からないこと
枌谷様：診断結果が出ていますね。71点です。
これが「どのくらい」となるんですが、100点満点で出ることはほぼありません。80点以上が出たのは、いろいろテストしたなかで今のところ3社だけです。
70点以上はちょこちょこあるんですが、かなり充実しているのが70点という感じなので、70点満点ぐらいで見てもらった方がいいかもしれないですね。
逆に60点で出た会社さんは割といいと思います。充実しているんですね。50点も普通という感じです。40点以下がやっぱり要改善という感じかなと思っております。
総評も出ます。これ結構厳しいんですよ。皆さん結構バキバキに言われちゃうような診断になっています。
200項目のチェック結果まで開示される
各項目ごとの評価では、何をどう評価しているかのチェック項目も全部開示する仕組みです。最終的には約200項目近くありますが、各項目に対して丸・バツ・三角でどんな状態だったかもチェックされます。
コンテンツ、情報設計、デザイン。デザインなんかは結構難しくて、目では見えないので、さっぱりしたシンプルなサイトが高い点数になることもあれば、しっかり作っているサイトが低く出ちゃったりもします。
ここら辺はAIの限界はあるんですが、それでも割と大外れしないことが多いかなという気がしますね。
投資対効果も出してくれるので、いくらぐらい採用サイトの改善にお金をかけるのがいいかも算出されます。
入力してもらった採用課題に対して、どんなことをやれるかというアドバイスも出ます。なので最初の課題を適当に入れちゃうと、アドバイスが自社にそぐわないものになってしまう。最初の課題を正確に入れるのが大事かなと思いますね。
そこから具体的な改善策まで出してくれるので、結構プチコンサルをこの段階でしてくれるような感じです。本当にお金がなくて自社である程度やれるのであれば、この項目に合わせてやるだけで、随分採用サイトは改善するんじゃないかなと思います。
人が手放してはいけないのは「課題設定」と「ダメ出し」
大事なのはやっぱり課題設定と最後のブラッシュアップです。ここはまだ自律的にはできなかったり、やってもらっても精度が低かったりします。
人間が最初の仕様を詰めて課題を具体化してあげるところと、その内容がちゃんといいものに仕上がっているのかを審査してあげるところ。
あと、出来上がったものを実際に使ってみて、ユーザー体験としてより良くなるかのブラッシュアップ。ここを人間がしっかりやることで、質の高いアウトプットが作れるようになるかなと思います。完全任せだと、やっぱりなかなかいいものにはなりません。
問いを立てる、AIをしばく。ダメ出しをするのは人間の役割なので、ここはやっぱり手放しちゃいけないかなと思っているところです。
AI活用で、採用担当者の仕事は上流にシフトする
――鈴木：ご覧いただいている方は人事の方や採用担当の方もいらっしゃいます。AI活用によって採用担当者に求められる仕事がどう変わっていくか、枌谷さんの視点をぜひいただければと。
枌谷様：採用は大きく、採用の責任者の方と、実務を回す担当者の方に分かれていることが比較的多いかなという気がします。この実務担当者の方がやる仕事の多くは、AIによってかなり置き換えられる気はします。
例えば、スカウトメールをいろんなプラットフォームで送るのって、めちゃくちゃ大変だと思うんですよね。大変なのでRPOの方にお任せしていることが多いと思うんですが、ああいう業務はエージェントをかませば自社で割とやれちゃう状況が作れたりします。
ある程度ルーチン化しているものや、法則が見い出せるものは置き換えられるんじゃないか。その発想を持っておくのが結構大事なんじゃないかなと思いますね。
逆にAIで難しいのは、採用の責任者の方がやるような仕事です。求める人物をちゃんと定義していくところですね。
「うちの会社が欲しい人材は、今の経営戦略を見るとこういう人材だ」「それを取るのは今の市場にはそんなに人がいないはずなので、こういうアプローチでやった方がいい」「自社の魅力はこういう切り口で打ち出した方がいい」といったところです。
もちろんAIと相談しながら出すというのはあると思うんですが、主導権はやっぱりこちらが握らないと。AIが、AIのデータ上にないものを勝手に先回りして出してくれるわけではありません。少なくともここ数年はそこまではいかないんじゃないかなという気がします。
だんだんと採用担当者の仕事が上流にシフトしていくという変化が起こるんじゃないかなと思います。
今すぐそうはならないとしても、自分の仕事がそうシフトしていく未来を見据えた上で、今の仕事をどこまでAIに任せるのか、外部のRPOのような会社に任せるのか、別のスタッフに任せるのか。見極めながら上流にシフトする絵を描いていくと、自分が将来どう変わるかが見えてくるんじゃないかなという気がしますね。
非エンジニアがぶつかる2つの壁と、その壊し方
――鈴木：上流を見据えながらも、まずは第一歩だと思います。非エンジニアがClaude Codeで業務ツールを内製する場合の、最初にぶつかる壁と対策はどうでしょうか。
枌谷様：私もClaude Codeの活用講座を何件か企業向けにやっていたりするんですが、いくつか壁があります。
1つ目は「なんか難しそう」という心理的な壁
まず心理的な壁として「なんか難しそう」というのがあるんですよね。
どうしても最初のインストールで黒い画面と向き合わなきゃいけないところもあって、その時点でちょっと心が折れる。「これは自分のやる世界じゃないな」感の壁を引いちゃう。
それによって、本当は理解できることなのに、心理的な壁が邪魔しちゃうというのが結構あったりします。なのでこれをまず超える必要があるかなと思っております。
私がお勧めしているのは、いきなりClaude Codeでなくてチャットに相談しながらやるのに慣れていくこと。だんだんこの壁が壊れていくという気がします。
例えば、採用の情報をSlackに自動で通知させるツールを作りたいとなった時に、SlackのAPIと連携させるためのトークンを管理画面から入手するみたいな行為が必要になります。もうこの時点で非エンジニアからすると「めちゃくちゃ分からないし難しい」となって避けちゃうと思うんです。
画面キャプチャを取って「これ今分からないんだけど、どうすればいい」とチャットに聞くと、全部教えてくれるんですよね。「このメニューを押してください」とか。そういうことをやっていく中で、だんだん自分でも使えそう感が出てきます。
2つ目は「自分の仕事でどう使うか分からない」発想の壁
心理的な壁がなくなると、次に起こる壁があります。なんとなく何ができるか分かったけど、自分の仕事でどう使えるか分からないという、応用の壁、発想の壁ですね。
これもさっきと同じで、チャットに相談する。あんまり具体的な相談でなくていいので「こういうことしたいんだけどどうすればいい」から聞いていくと、あとはチャット側でどんどん質問してくれます。これに慣れると、その壁も壊れていく。
どうしてもぶつかる壁はいくつかありますが、全部AIと相談することによって壊せていけるなという気がします。ちょっと頑張って食らいついていくという経験が、最初は大事かなと思いますね。
AIで自動化する未来はもちろんあります。一方でその移行期には、エンジニアリングを理解しておいた方が有利な時期が結構続く気がします。食わず嫌いせずに、エンジニアリング領域に踏み出してみるいい機会にするのがいいんじゃないかなという気がしますね。
「APIと繋ぐってこうなんだ」「他のサービスと繋ぐって、こういうものを入手すれば繋がるんだ」という世界観が分かるだけで、だいぶ利用イメージが広がる気がします。
質疑応答
AIに任せてよかった部分と、想定より人の介入が必要だった部分は
――鈴木：採用サイト診断ツールを作成する上で、AIに任せて良かった部分と、想定よりも人の介入が必要だった部分はありますでしょうか。
枌谷様：割と大きかったのが、当社の場合、採用サイトのチェックリストは元々ブログで公開していて、これがまるまる使えるかなというのが最初の発想だったんですが、実はチェックリスト自体をAIとやり取りしてカスタマイズしています。
チェックリストは162項目あるんですが、最終的に200項目ぐらいに増えているという感じです。
なぜカスタマイズする必要があったかというと、チェックリストの項目の中には、採用サイトをAIが認識するだけではよく分からないものが結構入っていたんですね。特に戦略軸の、例えば「求める人物がしっかり定義されているか」みたいなもの。サイトを見ても分からないんですよね。それはAIでも。
なので、採用サイトの中をクロールして見て分かる範囲、推測できる範囲でのチェック項目に作り直していきました。
この辺が、最初は「すぐできるだろう」と思ったけど、意外とチェックをちゃんと精査するのは自分の手でやらなきゃいけなかったなというところでした。めちゃくちゃ手間がかかったわけじゃないんですが、ポンポンといいものができるわけじゃないんだなというのは思ったところですね。
Claude Codeで便利だった使い方と、ClaudeとGPTの違い
――鈴木：Claude Codeを使う中で、これは想像以上に便利だと感じた機能や使い方はありますか。
枌谷様：Claude Codeは、データを全部突っ込んでおいて、そのデータを全部回した上で結果を出してくれる。それがやっぱりエージェントの強さだと思うんですよね。
さっきのチェックリストのカスタマイズで、途中段階で1回チェックリストをClaude Codeに渡したことがあります。
社内にいろんな提案資料や、採用サイトの作り方のノウハウ、ナレッジがかなり溜まっていて、いろんなPDFが存在しているんですね。これと照らし合わせた上で、もう少しチェックを補強できないかというやり取りをしていました。
ここはチャットのClaudeじゃなくて、やっぱりClaude Codeじゃないと。この大量にあるデータ、あとオウンドメディアのブログ記事とかも、エージェントの方が明らかに向いているところがありました。
こういう使い方が、本当に短いプロンプトだけで一気にできたというのは、本当にClaude Codeのすごさだったなと思いますね。
――鈴木：アイデア出しの部分で、ClaudeとGPTのプロンプトや質問の仕方に違いはありますでしょうか。
枌谷様：結論から言うとないというか。昔は確かに差があったりしましたけど、だんだん出力の傾向や得意・苦手の傾向はあるものの、プロンプトのテクニックじゃなくなってきていると思うところがあってですね。
それより、やり取りの中での問いの立て方の方が大事な気がします。だんだんプロンプトが雑になってきていますね、昔に比べると。逆に言うとあんまり意識していないという感じです。
結局ずっと進化し続けていますし、人間がプロンプトを工夫しなくていい方向に進化していっているので、あんまり意識しなくていいんじゃないかと私は思って使っています。
言語化・ナレッジ共有の文化を醸成するには
――鈴木：AIに関する質問ではありませんが、言語化・共有をする文化を醸成するために、社員や経営者に必要な行動や心がけはありますでしょうか。AI以前に「そもそもデータがない」「ナレッジがない」という問題ですね。
枌谷様：これはすごい根本の話ですよね。組織づくりから結構難しいんですけど。
1番大元は、やっぱりリーダーが言語化をする、言語化に対して前のめりに活動する。 それが全ての起点には必要な気がしております。経営者や部門長がそもそも言語化しないと、ボトムアップではなかなか言語化文化は生まれないかなという気はしますね。
その前提があった上での仕組みとして、当社には日報という文化があります。いわゆる日報なんですが、営業日報のような進捗を書く業務日報ではありません。
自分は今日何を感じていたか、どういうことを思ったか。自分の心のうちで思っていることを言語化して提出して帰るという文化があるんですよね。
これで言語化は自然とみんな磨かれている感じです。週に3回になっているので、勝手に磨かれるところがありますね。
トップが積極的であるのと同時に、メンバーが習慣として言語化しなければいけない習慣やルールをいかに作るか。うちの経験で言うと、そこが大事なポイントかなと思います。
逆にテクニック的な話で言うと、リーダーや部門長は忙しかったりするので、うちでよくあるのはインタビューをしちゃうというやり方です。
部門長が頭の中で描いていることや、現場が知りたい情報の項目は、大体AIと話せば出てきます。それを持っていきながら1時間ぐらいずっと質問する。言語がテキストになると相当な情報量になってくるので、あとはAIに任せてルール化したりマニュアル化したりというのも使えるかなと思います。
言語化のハードルは、思考勝負のところまで下がっている
余談ですが、言語化のハードルは下がっているなという気はしています。言語化のハードルは2つある気がしていて、1つは思考のハードル。そもそも深いことを考えていないと、言語化してもあんまり意味がないという問題です。
もう1つは、深く考えていても言葉にする能力を求められるところ。今は言葉でバーっと喋ったものをAIがちゃんと整理して表現してくれるので、思考さえ深ければ、こちらは割とやりやすくなっていると思うんですよね。
文章を書くのが苦手だったら、喋ってAIにまとめてもらうやり方ができます。とにかく思考勝負のところまで持っていくと、言語化がもう少し進むんじゃないかなという気はしますね。
診断ツールの精度と、人の判断との差分は
――鈴木：ツールによる診断結果の精度について、人が診断した結果との差分やAIならではの傾向は見られますか。
枌谷様：AIではまだ分からないのが、例えばデザインの質です。うっすらとは分かっている感じはあるんですけども、コードから推測しているだけだったりするので、人の目で見た時の印象と違うことが書いてあることがあります。
もう1つは戦略軸の妥当性。さすがにAIはなんとなくは分かっているけれども、本当のところはやっぱり分からない。類推で出しているという感じなので、ここは人間側の診断を重ねないと完全にはできないなというところは、今の段階で思っています。
AIならではの傾向としては、チェックに対して正確に診断するのは、やっぱり人間より上手だなという気がしています。
200項目もありますし、採用サイトは何十ページと持っていることが多い。その何十ページを200項目ごとにチェックするのは、人間がやると相当大変です。チェックの抜け漏れや「ここのチェックが甘かった」は絶対起こると思うんですよね。
確かに戦略やデザインはあやふやなところがありますが、総じてみると人間より診断の精度は高い気がしていて。こういうのはAIに任せた方が仕事としてはいいんじゃないかなと思います。地味なチェックをしっかり回してくれるのがAIならではの傾向かなという気はしますね。
CLAUDE.mdの中身と、会社情報の置き方は
――鈴木：CLAUDE.mdの中身を見せていただけるのであれば見せていただきたいです。人事業務を行うにあたり、Claude Codeに会社情報をどのように置くべきか教えていただきたいですと。
枌谷様：全然いいですよ。別に秘密でも何でもないし、もっと言うと恥ずかしいというか、あんまりちゃんとしていないかも。
CLAUDE.mdって、自分で作らないですよね。 もう本当にドシンプルなことしか書いていない気がします。
1番最初はチャットのClaudeに書いてもらって、あとは運用しながら、更新はClaude Codeに「これまでのやり取りからブラッシュアップしてください」というのを月1ぐらいでやっています。なのでほぼ自分で書いていないんですよね。
プロジェクトごとのCLAUDE.mdと、全体のCLAUDE.mdがあるんですけども、全体でも基本情報しか入っていないですね。
200行以内に収めるだったかな。シンプルにした方がいい説がありますし、Fableも複雑なプロンプトを打つなと公式に言われていますもんね。できるだけシンプルな方がいいと言われているので、あんまりいろいろ書かない運用の方がいいんじゃないかなという気はします。
評価軸の更新と、ツールのメンテナンス
――鈴木：人間の判断とギャップがあったものを、判断軸やプロンプトに反映するなどのアップデートは行っているのでしょうか。
枌谷様：途中経過のブラッシュアップで何をしていたかというと、実はチェックリストやアルゴリズムの見直しもちょこちょこかけていました。
実際の診断結果のレビューが出てくるんですが、読んでてしっくり来ないとか、浅いことしか言っていないみたいなことが途中段階ではありました。
こういうところは、こちら側から要求を出して、元の診断アルゴリズムの仕様の中に「ちゃんとこういうことを見ましょう」と入れ込むようなことを行っています。
――鈴木：作成したサイトやツールのメンテナンスについて。
枌谷様：大事な話だと思うので触れようと思うんですが、実は途中までのバージョンは私がやっていたんですが、今は社内のエンジニアに渡しています。
正式公開の直前にエンジニアにレビューしてもらって判明したことがいくつかあって。
1つは、AWSの環境に載せた時に「これだと都合が悪い」「動かない」みたいなことが発生しました。僕が元々作っていたバージョンは無限に並列でできるようになっていたんですが、サーバー負荷が高すぎるということで、同時には2件しか診断できないようにしてもらった。これはエンジニア側からの発案でした。
あとトークン消費の効率が悪かったというのも、エンジニア側のレビューで判明しました。1件診断するあたり200円ぐらい飛んでいたんですけれども、今は100円ちょっとまで抑えられるようになっています。
こういった効率化は、やっぱりエンジニアさんに見てもらえないとダメだなというのはあります。
エンジニアが手を加えていくと、だんだん私が管理している方が都合が悪いなとなってきて、今はもうエンジニアさんの管轄です。私が気になったところは直してとお願いしている感じになっています。
自分だけが使うツールなら自分だけでいいんですが、会社のオフィシャルなものとして出すとなると、セキュリティや中の仕組みが分かっているエンジニアさんにちゃんとチェックしてもらった方がいいなと思います。
AIによってエンジニアがいらないみたいな意見が時々出てきますが、私はむしろエンジニアの必要性はめちゃくちゃ高まっているなというのは実感しているところですね。
運用設計はどのタイミングで検討するか
――鈴木：PoCやバイブコーディング止まりを避けるには運用設計が大切な気がしますが、どのタイミングで運用を検討されていますか。
枌谷様：今は会社の中で明確に基準ができてきていて、一般公開、自社のドメイン配下に置く段階から、もうエンジニアのレビューを必ず入れるというのと、公開チェックというのが最近できてきました。
それこそトークンやAPIが外部に見える状態になっているようなことは、絶対にあってはいけないと思うんですけど、そういうチェックを全部入れてから上げる。しかもそれはエンジニアがレビューするという風にフローとして形式化していますので、公開直前にそういうレビューを入れているという感じですね。
最後に、枌谷氏はこう締めくくりました。
AIで採用業務も含めていろいろできるようになったのは実際そうであるものの、簡単に出せるという世界ではまだない。ただ、この一手間をかけることに慣れることが、今後のAI時代において優位になる、と。
みんながレベルの高いものを作れるようになれば、結局それが標準になる。標準になった時、手間を常に加えることで差別化ができる世界になる。AIにやらせて、そこに自分のアイデアを載せる。その作業自体に慣れる機会として使うといい、という言葉で締められました。
