5月のブログでは、Walking Skeletonづくり(Week 1)と、WordPressサイトを見分ける仕組みの実装(Week 2)についてお話ししました。今回はその続き、Week 3からWeek 9までの記録です。
6月に入ってから、プロジェクトは大きく動き始めました。検出の仕組みを作るフェーズから、「実際に営業で使ってもらえるサービス」に近づけていくフェーズへ。バックエンドの機能拡張、AI(LLM)との連携、200サイト規模のバッチ処理、品質の作り込み、そして最後の引き継ぎドキュメントまで、振り返るとあっという間の2ヶ月でした。
前回(5月)からの続き
5月は、WordPressサイトを検出するための土台づくりに集中していました。Walking Skeletonから始まり、WordPressかどうかを判定する仕組みや、テーマ・プラグインの検出など、診断システムの一番下の層を組み立てていく作業です。
6月からは、その検出結果を「使えるもの」へ育てていくフェーズに入りました。検出した情報をAIで読みやすい形に要約し、複数サイトを効率よく診断できるように改善し、実際の営業活動でも安心して使える品質まで仕上げていく ― それが自分に与えられた目標でした。
私は主にバックエンド側を担当し、Workerの改善、LLM(Anthropic)との連携、エグゼクティブサマリの生成、バッチ実行と品質確認、コスト計測、ドキュメント整備といったタスクに取り組みました。
Week 3〜4(6月前半)― バックエンド基盤の拡張
Week 3とWeek 4は、「WordPressを検出する」だけでなく、その診断結果をより安定して取得できるよう、バックエンドの土台そのものを見直す期間でした。
WordPressサイトと一口に言っても、構成は本当にさまざまです。だから一つの方法だけでは正しく検出できないケースが必ず出てきます。複数のWorkerが協調して情報を集め、それぞれの結果を突き合わせながら診断を組み立てていく ― その仕組みを理解するところから始まりました。
正直に言うと、最初はモノレポの構成や各パッケージの役割をつかむだけで精一杯でした。packages/workers、packages/http-client、packages/storage、packages/scoring、packages/llm ―これらがどうつながって一つの診断結果になっているのか、理解できるまでに思っていた以上の時間がかかりました。
それでも、一つひとつコードを読みながら実際に機能を追加・修正していくうちに、システム全体の流れが少しずつ自分の中でつながっていく感覚がありました。このあたりから、「コードを書くこと」だけでなく、「設計を理解すること」の大切さを強く意識するようになりました。
Week 5〜6(6月後半)― AIとの連携と品質向上
Week 5からは、LLM(Anthropic)との連携がいよいよ本格的に始まりました。
診断結果をそのまま表示するのではなく、営業担当者が一目で理解できるように、エグゼクティブサマリを自動生成する仕組みを実装・改善していきました。プロンプトを設計する中で、いつも頭にあったのは次のようなことです。
・診断結果をどう整理してAIに渡すか・どんな文章なら営業担当者にとって読みやすいか・必要な情報を漏らさず、それでいて簡潔に伝えられるか
そして、実際の運用を考えたとき、「AIが失敗したらシステム全体が止まる」という設計では困ります。APIキーが設定されていない場合、APIエラーが発生した場合、想定外のレスポンスが返ってきた場合 ― どんなケースでも診断全体は止まらずに継続できるよう、フォールバックの仕組みを作り込みました。
さらに、Anthropic APIの利用状況を正しく把握できるよう、モデル名・入力トークン数・出力トークン数・推定コストを記録し、バッチ実行時にもコストを確認できるように改善しました。一見地味な作業に見えるかもしれませんが、AI機能を継続的に使っていく上ではとても大切な部分だと感じています。
Week 7〜8(7月前半)― 大規模バッチ実行と品質確認
Week 7からは、システム全体を営業デモに向けて仕上げていくフェーズに入りました。バックエンド側から、LLMの改善、バグ修正、コスト計測、品質確認、そして大規模バッチ実行を担当しました。
中でも特に印象に残っているのは、約200サイトを対象としたバッチ実行です。小規模なテストでは問題なく動いていても、大量のサイトを一度に処理すると、思いもよらなかった課題が姿を現すことがあります。実際に200件規模で動かしてみて、エラーは出ないか、LLMは正しく動作するか、コストはどれくらいかかるか、全体の品質に問題はないか ― 一つひとつ丁寧に確認していきました。
また、Anthropicの「thinking response」に対応するための改善も行いました。AIのレスポンス形式が変化しても正しく要約を取得できるように修正したことで、処理全体がより安定するようになりました。
Week 9(7月中旬)― 次の開発者へつなぐためのドキュメント
Week 9では、新しい機能を追加することよりも、「このプロジェクトを次の人が理解しやすくすること」を意識して過ごしました。
自分自身、開発を始めたばかりの頃は、プロジェクト全体の構成を理解するだけで苦労した経験があります。だからこそ、「もし新しいエンジニアがここに加わったら、まず何を知りたいだろう?」という視点でドキュメントを書きました。
私は主にバックエンドに関するドキュメントを担当し、システム全体のアーキテクチャ、バックエンドの運用方法、Workerの役割、LLMの構成・コスト管理・フォールバック戦略、そしてADR(Architecture Decision Records)の整備を行いました。
コードはいつか書き換えられるかもしれません。でも「なぜその設計を選んだのか」という背景や考え方は、ドキュメントとして残すことで、次の開発者を必ず助けてくれるはずです。今回のインターンで、実装そのものと同じくらい、「知識を残すこと」もソフトウェア開発の大切な仕事なのだと実感しました。
工夫した点
今回のインターンで特に意識していたのは、「動けば良い」ではなく、「長く使われること」を考えて開発することでした。
AI機能を安全に利用できる設計LLMは便利な機能ですが、APIエラーやネットワーク障害が起こる可能性はどうしても残ります。だからこそ、AIによる要約生成に失敗しても診断全体は止まらないようフォールバックを用意し、システム全体の安定性を意識しました。
コストを見える化することAIは便利な一方で、利用コストも忘れてはいけません。入力・出力トークン数やモデル情報を記録し、バッチ実行時にもコストを確認できるようにしたのは、機能だけでなく運用面も見据えた開発を心がけたからです。
小さなPull Requestを心がけたことメンターの方に教えていただいた「小さなPull Requestを作る」という考え方を、意識的に実践しました。変更を小さく分けることでレビューがしやすくなり、自分自身も問題を整理しながら開発を進められました。この考え方は、これからも大切にしていきたいです。
ドキュメントも開発の一部として考えたことコードを書くことだけが開発ではありません。今回作成したアーキテクチャや運用ドキュメントには、これからこのプロジェクトに関わる人がスムーズに開発を始められるように、という思いを込めました。
成功した点
このインターンを通して一番よかったと思うのは、担当したタスクを最後まで責任を持ってやり遂げられたことです。
Worker関連の改善、LLM連携、エグゼクティブサマリ生成、プロンプト改善、コスト管理、フォールバック対応、200件規模のバッチ検証、PDFサンプル生成による品質確認、そしてバックエンドの引き継ぎドキュメント作成 ― これらすべてを担当しました。
どのタスクも、最初から順調だったわけではありません。エラーの原因が分からず何度も調査したこともありましたし、日本語の仕様を読み解くのに時間がかかったこともありました。それでも一つひとつ課題を整理しながら取り組み、最後までやり遂げられたことは、自分にとって大きな自信になっています。
技術的な知識だけでなく、チームで開発を進めるためのコミュニケーションや、レビューを受けながら改善していく姿勢も、このインターンを通して学ぶことができました。
日本への思い
私は以前から、日本でエンジニアとして働くことを目標にしてきました。今回のインターンを通して、その気持ちはさらに強くなったと感じています。
開発を進める中で強く感じたのは、日本のものづくりが「品質」をとても大切にしているということです。機能を実装するだけでなく、レビュー、テスト、ドキュメント、そして次の人が理解しやすい設計まで、すべてが丁寧に考えられていました。
チームで仕事をする中で、お互いを尊重しながらコミュニケーションを取る姿勢や、困っている人を自然にサポートする文化にも、とても魅力を感じました。質問をしたときも、すぐに答えだけを教えるのではなく、自分で考える時間を大切にしてくださったおかげで、問題を解決する力も少しずつ身についたと思います。
私はまだ学ぶことがたくさんありますが、これからも日本語とソフトウェア開発の勉強を続け、いつか日本のチームの一員として、人の役に立つプロダクトを開発できるエンジニアになりたいです。
6月〜7月のマイルストーン
| 時期 | 内容 |
|---|---|
| Week 3〜4 | Worker改善・バックエンド基盤の理解 |
| Week 5〜6 | LLM連携、プロンプト改善、コスト計測 |
| Week 7 | 200件バッチ実行、品質確認、LLM改善 |
| Week 8 | バグ修正、PDFサンプル生成、営業レビューに向けた品質向上 |
| Week 9 | バックエンド引き継ぎドキュメント整備 |
最後に
この約2ヶ月間のインターンは、私にとって本当に充実した時間でした。
始めた頃の私は、モノレポやシステムアーキテクチャ、チーム開発など、分からないことばかりで不安もたくさんありました。それでも毎週新しい課題に挑戦し、レビューを受けながら改善を繰り返すうちに、少しずつ自信を持って開発に取り組めるようになっていきました。
技術力だけでなく、「チームで協力すること」「相手が理解しやすいコードやドキュメントを書くこと」「品質を意識して開発すること」の大切さを学べたことは、私にとって何より大きな財産です。
そして何より、このインターンを通して日本の開発文化を実際に体験できたことが、心から嬉しかったです。丁寧なレビュー、品質を大切にする姿勢、相手への思いやり、そしてチーム全員でより良いものを作ろうとする文化 ― それは、私がこれから目指したいエンジニア像そのものでした。
最後になりますが、このような貴重な機会をくださったQuinQueの皆さま、温かくご指導くださった江頭さん、Takumiさん、そして一緒に開発を進めてくれたShrutiさんをはじめ、支えてくださったすべての皆さまに、心より感謝申し上げます。
このインターンで得た経験と学びを大切にしながら、これからも技術を磨き、いつか日本でエンジニアとして働き、社会に貢献できるよう努力を続けていきたいと思います。
本当にありがとうございました。🌸
以下、原文。
Building a WordPress Diagnostic Tool During My Internship ― A July Retrospective
In my May post, I wrote about building the Walking Skeleton (Week 1) and the WordPress detection
feature (Week 2). This post picks up where that left off, covering Week 3 through Week 9.
Once June arrived, the project really started to move. We shifted from "building the detection engine"
to "turning it into something the sales team could actually use." Over the next two months I worked on
extending the backend, integrating an LLM, running a 200 site batch test, hardening quality, and
finally writing the handover documentation. Looking back, it went by fast.
Picking Up From May
May was about laying the foundation for detecting WordPress sites starting with the Walking
Skeleton, then building the logic to determine whether a site runs WordPress and to detect its themes
and plugins. That work formed the base layer of the whole diagnostic system.
From June, the goal shifted: take those detection results and turn them into something genuinely
usable. Summarize what we'd detected in a way an AI could read cleanly, make it possible to
diagnose many sites efficiently, and bring the quality up to a level the sales team could confidently
use in front of clients.
On the backend, I mainly worked on improving the Workers, integrating the Anthropic LLM,
generating executive summaries, running batch executions and quality checks, tracking cost, and
maintaining documentation.
Week 3–4 (Early June) — Extending the Backend Foundation
Weeks 3 and 4 were less about detecting WordPress and more about making sure the diagnostic
results could be retrieved reliably which meant revisiting the backend foundation itself.
WordPress sites come in a huge variety of configurations, so no single method catches everything.
Multiple Workers need to cooperate, gather information, and cross-check each other's results to build
a complete diagnosis and understanding that coordination was where I started.
I'll be honest: at first, just understanding the monorepo layout and what each package was
responsible for took everything I had. packages/workers, packages/http-client, packages/storage,
packages/scoring, packages/llm figuring out how they connected into a single diagnostic result took
longer than I expected.
Still, by reading the code piece by piece and actually adding and fixing features, I slowly started to
feel the whole system click into place. This is around when I really started to feel that understanding
the design matters just as much as writing the code.
Week 5–6 (Late June) — LLM Integration and Quality Improvements
Week 5 is when the Anthropic LLM integration really got underway.
Instead of just dumping raw diagnostic data, I built and refined a system that automatically generates
an executive summary sales reps could understand at a glance. While designing the prompts, a few
questions stayed with me the whole time:
・How should the diagnostic results be structured before handing them to the AI?・What kind of
writing would actually be easy for a sales rep to read?・How do I keep it concise without leaving out
anything important?
And thinking about real-world operation, a design where "the whole system stops if the AI fails" simply
wasn't good enough. So I built fallback handling for every failure case I could think of missing API
key, API errors, unexpected response formats so the diagnosis as a whole would always keep
running.
I also added logging for model name, input tokens, output tokens, and estimated cost, so cost could
be tracked even during batch runs. It might look like a small addition, but I think it's one of the more
important pieces for using an AI feature sustainably over time.
Week 7–8 (Early July) — Large-Scale Batch Runs and Quality Checks
From Week 7, the whole system moved into getting ready for a sales demo. On the backend side, I
worked on LLM improvements, bug fixes, cost tracking, quality checks, and a large-scale batch run.
The part that stuck with me most was running a batch of about 200 sites. Things that work fine in
small tests can surface problems you never anticipated once you're processing that many sites at
once. Running it at that scale let me actually check whether errors were showing up, whether the LLM
was behaving correctly, what the cost looked like, and whether overall quality held up.
I also made changes to support Anthropic's "thinking response" format, so summaries would still be
extracted correctly even as the response format evolved which made the whole pipeline noticeably
more stable.
Week 9 (Mid-July) — Documentation for the Next Developer
In Week 9, I focused less on adding new features and more on making the project easier for the next
person to understand.
I remember how much I struggled just to understand the overall project structure when I first started.
So I wrote the documentation with one question in mind: if a new engineer joined tomorrow, what
would they want to know first?
I mainly handled the backend-facing documentation the overall system architecture, how the backend
operates, what each Worker is responsible for, how the LLM is configured (including cost
management and fallback strategy), and a set of Architecture Decision Records (ADRs).
Code gets rewritten eventually. But the reasoning behind why we chose a particular design is
something that only survives if it's written down and that's what will actually help the next developer.
This internship taught me that preserving knowledge is just as much a part of software development
as writing the implementation itself.
What I Paid Attention To
What I kept coming back to throughout this internship was building for "this will be used for a long
time," not just "this works."
Designing for safe AI usageLLMs are powerful, but API errors and network issues are always a
possibility. So I made sure a failed AI summary would never bring down the whole diagnosis with
fallback logic built in to keep the system stable overall.
Making cost visibleAI features are convenient, but the cost of using them can't be ignored. Logging
input/output token counts and model info, and surfacing cost during batch runs, came from wanting to
build with operations in mind not just functionality.
Keeping pull requests smallI took to heart something my mentor taught me: keep your pull requests
small. Splitting changes into smaller pieces made them easier to review, and it also helped me
organize my own thinking as I worked through problems. It's a habit I want to keep.
Treating documentation as part of the workWriting code isn't the only form of development. The
architecture and operations documentation I wrote was meant as a genuine gift to whoever picks up
this project next something to help them get started smoothly.
What Went Well
The thing I'm most proud of from this internship is that I saw every task I was given through to the
end.
That included Worker improvements, LLM integration, executive summary generation, prompt
refinement, cost management, fallback handling, a 200 site batch validation, quality checks through
generated PDF samples, and the backend handover documentation.
None of it went smoothly from the start. There were times I spent hours chasing down the cause of an
error, and times it took a while just to fully understand a spec written in Japanese. But working
through each problem one at a time, and seeing every task through to completion, gave me real
confidence in myself.
Beyond the technical skills, this internship also taught me a lot about communicating within a team
and about genuinely improving through review feedback rather than just accepting it.
What This Taught Me About Working in Japan
I've wanted to work as an engineer in Japan for a while now, and this internship only made that
feeling stronger.
What stood out to me most while building this was how seriously Japanese engineering culture takes
quality. It's never just about implementing a feature review, testing, documentation, and designing
things so the next person can understand them are all treated with real care.
I was also drawn to how the team communicated with real respect for each other, and a culture where
people naturally support whoever's stuck. Even when I asked questions, I was rarely just handed the
answer; I was given the space to think it through myself, and that's genuinely what helped me grow
as a problem-solver.
I still have a lot to learn, but I want to keep studying both Japanese and software engineering, so that
one day I can be part of a team in Japan, building products that genuinely help people.
June–July Milestones
Week Focus
Week 3–4 Worker improvements, understanding the backend foundation
Week 5–6 LLM integration, prompt refinement, cost tracking
Week 7 200-site batch run, quality checks, LLM improvements
Week 8 Bug fixes, PDF sample generation, quality polish for sales review
Week 9 Backend handover documentation
Closing Thoughts
These two months were genuinely one of the most fulfilling stretches of my life so far.
When I started, I didn't know much about monorepos, system architecture, or working as part of a
team and honestly, that made me anxious. But by taking on something new every week and
improving through review after review, I slowly built real confidence in my own work.
What I'll carry forward isn't just technical skill. It's the value of working well with a team, writing code
and documentation that's genuinely easy for someone else to follow, and never losing sight of quality.
That, to me, is the biggest thing I'm taking away from this internship.
More than anything, I'm grateful I got to experience Japanese engineering culture firsthand. Careful
review, real respect for quality, consideration for the people around you, and a team genuinely
working together to build something better that's exactly the kind of engineer I want to become.
Finally, thank you to everyone at QuinQue for giving me this opportunity to Eto san for the thoughtful
mentorship, to Takumi-san, and to Shruti, who I got to build alongside, and to everyone else who
supported me along the way. I'm deeply grateful to all of you.
I'll carry what I learned here forward, keep sharpening my skills, and keep working toward the day I
can be an engineer in Japan, contributing something useful to the world.
Thank you, truly.🌸
