インターン前半終了、ここまでで学んだこと

Published on: 2026/08/21

6週間のインターンのうち、前半の3週間が終わりました。

6週間のうち、前半と後半で部署が変わる形式になっています。前半はLYのクラウドプラットフォームであるFlavaで、サービス間通信をするときの認証認可システムを作っていました。

今回は、インターン前半でやったことと、AI駆動開発をして感じたこと、初めて人からコードレビューを受けて学んだことを書いていきます。

まずはAthenzやFlavaについて知るところから

最初はAthenzやFlavaなど、これから作るシステムに関係する前提知識を入れるところから始まりました。

その後にDesign Docを読んで、書かれている内容を実装していきました。 今回のインターンでは、ほとんどがDesign Docに書かれていることを実装する作業でした。

作業の流れとしては、前提知識を勉強して、Design Docを読んで、実装して、テストを書いて、PRを出してレビューをもらうという感じです。

MarkdownとMermaid図で認識を合わせた

今回の開発では、実装やテストだけでなく、READMEなどのドキュメント作成もAIにやってもらいました。

もともと用意されていたMarkdownのドキュメントやMermaid図を見ながら、実装を進めました。

こういう資料があると、人間とAIの間でも認識を合わせやすいんだろうなと思いました。 Mermaid図は人間にとって処理の流れを理解しやすいですし、コードとして書かれているのでAIにとっても扱いやすそうです。

実装からテストまでほとんどAI

今回の開発では、実装からテストまでほとんどAIにやってもらいました。 PRを出すための準備やREADMEの作成もAIです。

作ってほしいものを指示すれば、全部作れてしまうという感じでした。 もちろんDesign Docが整理されていたからというのはありますが、実装がめちゃくちゃ速かったです。

大きなサービスの開発で、ここまでAIに任せて進められるのかというのは結構面白かったです。

ドキュメントにないことはAIも判断できない

AIに任せれば何でもうまくいくわけではありませんでした。

コードレビューで、「何をしているのかは分かるが、なぜこれをしているのか分からない」と指摘された部分がありました。

APIの仕様が通常とは少し違う部分で、その仕様に合わせるために独自のエラーハンドラを実装していました。 AIが「これは通常と違うけど、この仕様でよいのか」と聞いてきたときに、自分が「まあいいでしょ」と答えて、そのまま実装を進めていた部分です。 その結果、独自のエラーハンドラを使ったことで、周辺の処理もおかしなことになっていました。

バリデーションでも、本来は通らなければいけない例外的なケースが通らない実装になってしまったことがありました。 これはDesign Docには載っていないFlavaの仕様に関係する部分でした。

昔使っていたAthenzとの互換性を持たせておく部分があり、今回作っているのもFlavaでAthenzを使いやすくするための仕組みに関係しています。 こういう既存の仕様との互換性は、Design Docだけ読んでいても分からなかったと思います。

この経験から、通常とは違う実装をしているなら、その理由をコメントに残しておくべきだと学びました。 コードを読めば何をしているのかは分かっても、なぜそうしているのかまでは分からないからです。

また、あとからおかしくなりそうな部分を見つけたなら、「まあそういうものか」で済ませず、なぜこの仕様になっているのかを先に確認するべきだと思いました。 早めに確認していれば、変な実装を進めてから修正することもなかったはずです。

動けばいいコードから運用しやすいコードへ

AIにある程度指示を入れないと、とりあえず動くコードが出てきます。 読みやすさや運用のしやすさまで考えてもらうには、追加で指示が必要でした。

AIは指示すれば直してくれますが、何を直すべきかを判断するのは自分です。

今回初めて、ちゃんと人からコードレビューを受けました。 これまではコードの良し悪しについてAIとしか話したことがありませんでした。 AIにレビューさせて、もうこれ以上改善することはないと言われたコードに、人間からどんな指摘が来るのかは結構楽しみでした。

実際のレビューでは、コメントが多分15個ぐらいありました。 最初はコメントが多すぎてちょっと恥ずかったです。 ただ、よく読んでみるとかなり勉強になることが多くて、途中から面白くなってきました。

AIにコードを見てもらうのとは別で、実際にそのシステムを知っている人から見てもらえるのは大きいなと感じました。 ドキュメントが完璧ではないときに、致命的になりそうな部分を見分ける嗅覚のようなものも大事だと思います。

レビューでは、責務分離ができていなくて、ファイル名と中身が一致していない部分も指摘されました。 そもそもコードが読みにくいという指摘もありました。

このレビューを受けてからは、AIに実装を頼むときも、動くかどうかだけでなくコードの構成を意識して指示するようになりました。 例えば「このファイルは名前に対して役割が大きすぎるから、適切に分割して」と指示すると、責務分離も改善できました。

動くものを作るだけならAIでもできますが、実務で使うコードとしてはそれだけでは足りません。

一発で完璧なコードが出てくることはないので、自分なりの好みを持っておくのも重要だと感じました。 それは読みやすさだったり、運用のしやすさだったりに関係してくる気がします。 まあ、これは実際に読みにくいコードに当たらないと分からないのかもしれません。

大きなサービスに自分の実装が入る

今回のインターンでは、リポジトリをまるまる1つ作らせてもらいました。 大きなサービスに対して自分の実装が入るのは、まあやっぱり気持ちいいです。

実装の多くをAIにやってもらったとしても、前提知識を入れたり、Design Docを読んだり、出力を確認したり、レビューを受けたりする必要はあります。 AIに任せる部分が増えても、自分が何も考えなくていいわけではありませんでした。

むしろ、ドキュメントの曖昧な部分を見つけて確認したり、運用しやすいコードになっているかを考えたりすることが必要になります。

後半は別の部署でインターンをすることになります。 前半で学んだことを活かしつつ、今度は曖昧な部分を「まあそういうものか」で済ませず、早めに確認するようにしたいです。