PKSHA Technologyエンジニア サマーインターン 体験記

みなさんこんにちは！みーやと申します。

この度、2025 年 9 月に 株式会社 PKSHA Technology（以下 PKSHA）にて 2 weeks ソフトウェア・エンジニア サマーインターン（以下インターン）に参加させていただきました。
この記事では、インターン参加のきっかけからインターンの内容と開発エピソード、参加して感じたことまで、可能な限り幅広く深くご紹介します。エンジニア、特にフルスタックとしてのキャリアに興味がある学生、 PKSHA のインターンに参加してみたい学生にぜひ読んでいただければと思います。

チームメンバーとの写真

自己紹介

みーや（Miyata Yusaku）
高専から３年次編入した、九州大学の情報系大学院生です。Web アプリケーション、とくにフロントエンド（TypeScript, React, Next.js）を扱っています。
学部時代の長期インターンとしては、東大スタートアップでのオークションサイト、人材系企業での質問箱サービス、コンサルティングファームでの教育系プロダクトなどの開発を行ってきました。
大学院の長期インターンとしては、株式会社マネーフォワード、株式会社 LayerX などで活動してきました。
福岡未踏への参加経験もあり、プログラミングサークルのメンターも担当しています。

ポートフォリオ：https://pkmiya.net/
X：https://x.com/pkmiya__

参加のきっかけ

就活サイトでスカウトが来たことや、PKSHA でかつてインターンをして入社した先輩がいたことがきっかけです。志望動機としては、私が将来ジェネラリストなエンジニアを目指すキャリアの一つにしていて、ビジネスサイドの視点やドメイン知識などが重要だと考えており、この点で PKSHA と価値観が一致するのではないかと考えた点、アウトプットや情報透明性を大事にしているカルチャーがフィットすると考えた点の大きく２つがあります。また、PKSHA の事業やインターンの内容が、私の開発スタイルや経験と相性が良いのではと思ったためです。

インターンの概要

まず、PKSHA についてご紹介します。PKSHA は、主に自然言語処理、画像認識、機械学習/深層学習技術に関わるアルゴリズムソリューションを展開している企業です^[1]。
続いて、インターンの概要をご紹介します。今回のインターンは短期間で企画から開発、プレゼンまでを一気通貫で行うものの、一般的なハッカソンとは異なり比較的長めの時間を取って実施されました。以下に形式を記載します。

項目	内容
期日	2 週間（10 日間）
場所	対面（PKSHA オフィス、本郷）
職種	ソフトウェア・エンジニア（SWE）
形式	ハッカソン形式・チームごと
テーマ	「人の能力を拡張し、コミュニケーションの負を解消する AI エージェントを開発せよ」
利用技術	特に指定なし（Python ＋ FastAPI や React/Next.js など）

内容としては、PKSHA が有するソリューションである「PKSHA FAQ」の新たな価値提案をする、というものです。PKSHA FAQ とは、誰でも簡単に FAQ の作成・公開・分析・運用改善ができるナレッジマネジメントシステムです^[2]。
インターンの内容としては、FAQ そのものや、PKSHA FAQ に対する理解を深めた上で、ユーザの抱える本質的な課題を特定し、それを解決するようなシステムを設計・実装し、デモありのプレゼンまで行うものです。

そのほかの内容（待遇など）は、SpeakerDeck に投稿されたインターン説明会資料^[3]が参考になると思います。

インターンの実施内容

上記の通り、2 週間で PKSHA FAQ の理解、ヒアリング、アイデア出し、設計、実装、プレゼンまでを行いました。なおメンターとしてエンジニアの社員の方に 1 名ずつ各チームをサポートいただきました。
私たち（チーム 4 人）の開発における流れや発表した内容をベースに、インターン当時の様子を紹介します。

オンボーディング

1 日目の午前中は、オンボーディングとして、PKSHA の企業紹介、PKSHA FAQ のプロダクト紹介、インターンのテーマ発表、メンターの紹介、学生の自己紹介が行われました。
また、開発環境として、MacBook Pro や 各種 SaaS 環境を貸与いただきました！インターンの内容や開発環境を整えていただいた点から、インターン生だと意識することなく、実務と同様にプロフェッショナルのエンジニアとしての振る舞いがまさに求められているのだと感じました。

インターンのテーマが発表されたときの様子（PKSHA 採用担当公式 X より^[4]）

アイデア出し、要件定義

1 日目の午後から 3 日目の午前にかけて、アイデア出しと要件定義を進めました。
私たちのチームでは、現状の FAQ の（FAQ プロダクトの利用者、たとえば一般企業のカスタマーサポート担当などが抱えるとされる）課題感が複数与えられた中で、ナレッジの陳腐化に着目し、「FAQ が現状のシステムに一致していない」事例があると特定しました。また、この事例が起きた際に一般的にどのような業務フローが行われるのか考え、この事例がユーザにとって本当に解決して嬉しいものなのかを検証するための仮説を複数立てました。

• 業務フロー：この事例の解決にあたり、一般的に考えるべきこと
  • FAQ が現状のシステムに一致していない部分があるか
  • その場合、具体的に FAQ のどの部分が一致していないか
  • その場合、どのような内容に更新すべきか
• 仮説：この事例がユーザにとって本当に解決して嬉しいものなのか
  • ナレッジの陳腐化が、企業担当者にとっても利用者にとっても大きな問題か？
  • どの FAQ が古いのかを探す作業が、企業担当者にとって大変か？
  • FAQ をどのような内容に更新すべきか考える作業が、企業担当者にとって大変か？

アイデア発表

3 日目の午後はアイデア発表が行われました。各チームが、ターゲットとするペルソナや課題、ソリューションの概要を提案し、他のチームの担当メンター社員のみなさんから質問やアドバイスをいただきました。
私たちのチームでは、3 日目午前までに話し合った内容をもとに、以下のソリューションを提案しました。（私は体調不良のため 2 日目と 3 日目はお休みしたため、このアイデア発表はチームメンバーに任せることとなりました 💦）

私たちのアイデア

• 背景：既存の FAQ は膨大な件数存在している。FAQ の更新が必要となった場合、どの FAQ を更新すべきか特定する作業とどのような内容に更新すべきか内容を考える作業は、企業担当者にとって負担となっている
• 提案：更新の根拠となるドキュメントをもとに、FAQ の更新を担当者に提案する AI エージェントを提案。
• めざす姿：FAQ の更新にかかる担当者の負担を大幅に減らし、FAQ の質を担保する。

この記事はインターン終了から 2 週間経過したタイミングで執筆しているので、実施した内容や印象的なエピソードなど、一部記憶が定かではありません 💦 しかし、このアイデア発表に対するフィードバックは手厚くいただいた覚えがあるのですが、当時のアイデアは深掘りが甘く、解像度がもっとぼんやりしていたはずです。

システム設計

アイデア発表の後は、発表までひたすら設計・開発を行いました。話し合いの結果、私たちのプロダクトのアーキテクチャは以下のような形で決定しました。

私たちのプロダクトのアーキテクチャ

クラウドサービスとして AWS の環境を提供いただいたため、AWS をベースとした構成となっています。
プロダクトは Web アプリとして実装しており、Web アプリを Amazon S3 に展開し、バックエンドサーバは Docker コンテナとして起動できる形で ECS Fargate に載せ、データは Amazon DynamoDB に格納しています。AI エージェントの実装では、FAQ の提案に Amazon Bedrock,FAQ の検索に Amazon OpenSearch, データ取得に AWS Lambda, AWS Step Functions を利用しています。

以降、主に以下のような分担で実装を進めました。

• 自分：フロントエンド（全体把握、プレゼン準備、Web アプリ設計・実装）
• メンバー 1：バックエンド、インフラ（アーキテクチャ設計、インフラ実装、API 実装）
• メンバー 2：アルゴリズム（アルゴリズム検証、推論処理実装）
• メンバー 3：バッチ処理（インフラ実装、データ保存、ベクトル化）

開発（フェーズ 1）

開発（フェーズ 1）では、6 日目の午後の中間発表に向け、実装を進めました。

開発を始めるにあたり、まずは開発環境とインフラの構築を行いました。
開発環境に関して、私たちのチームは AI Agent を利用した Vibe Coding 主体で実装を進める方針を立てました。背景としては、主に以下の点が挙げられます。

• ２週間という短い期間で、アイデア出し・設計・実装・プレゼンまでの一気通貫したフローを完了させる必要があった点
• システムのアーキテクチャや仕様の観点からコードの記述量が与えられた時間に対し非常に多かった点
• AI ソリューションを提案するための、技術的あるいは価値的な検証を高速で回す必要があり、ここに人的リソースを割きたかった点、

これらの理由の一部は後付けになってしまっているかもしれませんが、Vibe Coding を導入して良かった点、という言い方もできるかもしれません。
実際には、AWS Bedrock にて Claude Code, Claude Code Action を利用する形で Vibe Coding を導入しました。Claude Code を直接利用しなかった理由としては、会社の提供する SaaS 以外の利用が NG であったこと（Cursor Pro は OK でした）、与えられた AWS 環境をフルに活用したかったためです。環境構築においては、以下の記事を参考にしました。

https://zenn.dev/feelingover/articles/269de4c26555ce

上記によって Vibe Coding の環境が整った後にインフラの構築を行いました。インフラに詳しいメンバー主体で、上記に掲載しているアーキテクチャに沿って AWS 各種環境の設定や Terraform の実装、デプロイや動作確認を進めました。
インフラの構築と並行して、各メンバーはそれぞれ担当するタスクを進めました。特に、他のチームと比べて私たちはアイデア発表の時点でアイデアに対する厳しい声をいただいていました。そのため、私はプレゼン資料における論理の流れの整理やフロントエンドのデモ画面の実装を重点的に進めました。

フロントエンドの実装ももちろん Vibe Coding で行いましたが、デモ画面（モックデータ）の実装は、以下のような流れで行いました。

1. UI をホワイトボードに書く。書きながら、画面の名称、ユーザが何をするのか、画面がどのような挙動を示すのか、ユースケースの想定漏れはないか、などを考えつつ進めました。

2. 考えた UI についてメンバーとディスカッションする。チームメンバーに設計した UI を見せ、想定する使い方を説明しました。適宜話し合いを行って UI をブラッシュアップしました。

3. アプリの挙動を言語化する。ステップ 1 と 2 ではグラフィック主体の記述をしていましたが、Vibe Coding に向け AI が分かりやすい体裁とするため、使い方の流れ、画面の目的、表示されるコンポーネント、画面の挙動などを漏れがないよう詳細に記述しました。人間にとっても分かりやすい操作マニュアルであり、AI にとっても分かりやすいプロンプトとなるよう工夫しました。自分が記述していたプロンプトは以下のようなイメージです。

   FAQの更新作業にあたり、類似FAQの一覧や新たなFAQの内容を提案するAIエージェント型Webアプリ
   Frontend の技術スタック：TypeScript v5, React v19, Next.js v15.1, Tailwind CSS v3.4, shadcn-ui
   以下の仕様に沿って各画面を順番に実装して。APIつなぎこみは行わず、ダミーのデータや読み込みを利用する。
   
   1. ドキュメントアップロード画面。ユーザがリリースノート等のドキュメントをアップロードするための画面。アップロード用フィールド、ファイルごとのアップロード状況表示、次の画面に進むボタンが用意されている。ファイルは個数上限 1個、形式はPDFのみ、サイズ上限 10 MB。ファイルが1個以上アップロードされ、かつアップロード中のファイルがなければ次の画面に進める。
   2. ...
   

普段から Vibe Coding を行っているフルスタック・エンジニアなどの方々からすれば、このプロンプトでも詰めは甘い方かもしれないですね笑。上記のプロンプトを Cursor の Agent モードに投げることで、フロントエンドのデモ画面 4~5 つをおよそ 1 時間足らずで実装することができました。

中間発表

6 日目の午後に中間発表が行われました。各チームが、最終発表を目指して実装中くらいの完成度でプレゼンを行いました。私たちのチームでは、以下のようなフィードバックをいただきました。

• アイデア発表と比べて、プレゼンの構成や内容が明らかに分かりやすくなっている
• デモ画面がシンプルでモダンなデザイン。洗練されていて使いやすそう
• 関連 FAQ が見つからなかった場合など、ユーザが新たに FAQ を作成したい場合があるかもしれないので、その動線も設計すると使いやすくなりそう
• 生成 AI による提案の正当性をより納得あるものにするため、プレゼンに検証内容を記載する場合は内容の整合性に気をつけると良い

総じてアイデア発表のときと比べて提案の解像度が高まったことに対する高い評価をいただきつつ、さらに改善する見込みがあることを教えていただきました。

開発（フェーズ 2）

中間発表以降は、最終発表に向け、できていない部分やアドバイスをいただいた箇所の実装を進めていきました。
ここでは、開発中に遭遇したバグについてご紹介します。

「バックエンドで定義した型がうまく解釈されず、フロントエンドで Any 型になる」
私たちのプロジェクトでは、OpenAPI Generator CLI を利用しており、バックエンドのコードからフロントエンドの API クライアントを自動生成する環境を整えていました。これにより、API を叩く関数やリクエスト・レスポンスの型が自動的に用意されるため、開発速度、保守性、開発者体験などが格段に向上しています。しかし、開発中、Python で 辞書型などを使って複雑な（不適切な？）型を定義すると、TypeScript で Any 型が生成されてしまうことがありました。この問題は、バックエンドにある該当する型定義を見直すことで解決しました。

その他、生成モデルの質が低い、ベクトル化データが生成されない、などのバグもありましたが、最終発表までになんとかシステム全体をつなぎこみ、動作させることができました。

最終発表

インターン 10 日目＝最終日、午後から最終発表が行われました！オンボーディングの際と同じ広い会場で、私たちのチームは１番目の発表だったためとても緊張しました。プレゼン自体は、プレゼン準備をメインで担当したメンバー２人で発表しつつ、質疑応答は全メンバーで回答する形で行いました。

発表の際にいただいたフィードバック・質問を一部ご紹介します。

• プレゼンの流れが明確で、聞いていて理解しやすかった
• アーキテクチャ構成が実務的で完成度が高い
• ユースケースをもう少し広くカバーするとよい（例：本当は更新したいはずだった FAQ が、類似 FAQ 検索結果に表示されなかった時は、ユーザはどうすればよいのか）

他のチームの発表も聞いたところ、どこも課題の解像度・プロダクトの完成度がとても高くて驚きました。まさにレベルの高い学生のみなさんが集まっていて、非常に焦りを感じた瞬間でした...！

振り返り会

最終発表の後は、社員の方と 1on1 を行い、自分やチーム全体の振る舞いがどうだったかについて議論したり、フィードバックをいただくことができました。また、チームごとに振り返り会を行い、ホワイトボード、ふせん、「Fun, Learn, Done」の 3 カテゴリのベン図を使って、インターン中のエピソードを振り返りました。この瞬間が一番緊張感が抜けた状態でチームメンバーと話せたので、とても楽しかった覚えがあります。

チームでの振り返り会

インターン内容のまとめ

日記が長くなってしまったので、このインターンで行ったことを簡潔にまとめます。

• 2 週間、チームごと、1 チーム 4 名という形式で、PKHSA FAQ プロダクトを活用して、テーマ「人の能力を拡張し、コミュニケーションの負を解消する AI エージェントを開発せよ」にぴったりなソリューションを、要件定義から設計・実装、プレゼンまで一気通貫で行った。
• 私たちのチームでは、企業担当者が行う FAQ の更新作業のコストを減らすため、ユーザがアップロードしたドキュメントをもとに、更新すべき FAQ の一覧と更新後の FAQ の内容を提示する AI エージェントを提案した。これにより、FAQ の検索・更新で起こりうる抜け漏れを減らし、利用者のために整ったナレッジ環境を提供する。
• 実装には、AWS 環境をフルに活用した。Web アプリのために S3, ECS, DynamoDB を利用し、AI 提案のために Bedrock や OpenSearch を利用した。

インターンを振り返って

インターンを振り返って、得た学びやいただいたフィードバックをご紹介します。

フィードバック

社員さんとの 1on1 等で、個人としていただいたフィードバックの一部をご紹介します。

• インターン開始から終了まで、コミュニケーションが豊富だった。メンションややってほしいことの相談などを臆することなく行っていた
• アイデア発表から中間発表にかけての改善が明らかだった。特に、フロントエンドの文面で強みを発揮していた
• 今後はバックエンドやインフラにも積極的に関わっていけるとよい
• Claude code、運営も悪いので。ぜひエピソードにしてね

リーダーシップやフロントエンドといった文脈では強みを発揮できる一方、バックエンドやインフラに対する理解が浅い点は、自分の認識と一致するところです。市場価値や自分にとってのやりがいなどといった理由からフルスタックなキャリアを目指す上で、今後伸ばしていきたいと強く感じています。

得た学び

一つ目は、課題の深掘りやペインの理解の難しさと大切さです。具体的には、以下を実践することで課題の解像度を高めることができそうだと感じました。

• 記述された文章を丁寧に追う。（例：「〜〜が面倒」とあったならば、それはなぜ？どのように（様子）？どのくらい（量・頻度））
• 懐疑的になる。（例：この機能で本当に解決できるか、そもそもこの機能は必要か？）

最近読んだ以下の記事でも思ったのですが、適切な言語化こそ、容易には習得できないがクリティカルな部分だと実感しました。
https://speakerdeck.com/natty_natty254/ti-an-reberuwoshang-getemitara-si-no-ti-an-ga-jin-bu-ninatuteitajian

この件を ChatGPT に聞いてみたのですが、まさに私が求めているものを言語化してくれました。自分にとって非常にためになったので、ぜひ言語化させてください。

「Forward Deployed Enginner がビズサイドと対等に渡り合うための課題検証・要件定義チェックリスト」 (feat. ChatGPT GPT 5)

1. 課題の本質を確認する（Problem）

   • 課題は「ユーザーの具体的な行動・状況」に基づいて定義されているか？（抽象的な「使いにくい」ではなく「◯◯ をする時に △△ が不便」）
   • この課題を抱えるユーザーは誰か？ペルソナを明確にしているか？
   • 課題を解決しないままにした場合、どんな悪影響があるか？（時間の浪費・コスト増・心理的負担など）
   • 既存の代替手段（Excel, LINE, 紙など）はどう機能しているか？

2. 課題解決の価値を問う（Desirability）

   • 課題が解決されたとき、ユーザーは「本当に嬉しい」と感じるか？
   • その解決によるインパクトは「Nice to have」ではなく「Must have」か？
   • ユーザーはそのために時間・お金・行動を変える意思があるか？（=ペインの強さ）
   • “Jobs To Be Done” の観点で「ユーザーが達成したい進歩」は定義されているか？

3. 解決策の妥当性を検討する（Solution）

   • この機能は本当に課題解決に直結するか？（単なる「便利そう」に留まっていないか）
   • 他のアプローチと比べて、シンプルで効果的な解決になっているか？
   • 解決策の効果をどう測るか（KPI, 定性フィードバックなど）が決まっているか？
   • MVP で小さく検証可能な形に落とし込めるか？

4. 機能要件の過不足をチェック（Sufficiency）

   • 「やりたいこと」を一通り実現できる最小限の機能が揃っているか？
   • 不要な複雑さや過剰な機能を盛り込んでいないか？
   • 想定ユーザーのユースケースをカバーできているか？
   • 将来拡張のための余地（API 設計、スキーマ設計など）は意識されているか？

5. 実現性を見極める（Feasibility & Viability）

   • 技術的に実装可能か？既存システムとの統合はどうか？
   • コストやスケジュールはビジネス的に許容できる範囲か？
   • 法規制・セキュリティ・運用負荷の観点で無理はないか？
   • 将来のスケールに耐えられる設計か？

6. コミュニケーション観点（FDE としての立ち位置）

   • ビズサイドが提示した「解決策」ではなく、その背後の「課題」をヒアリングできたか？
   • 「なぜそれが必要か？」を 5 回ぐらい掘り下げて聞いたか？
   • 技術的トレードオフ（早さ vs 拡張性、費用 vs ユーザー体験）を言語化して議論できているか？
   • 課題 → 解決策 → 要件が論理的に接続されているか？

これらのポイントを、まさに要件定義から機能の仕様に落とし込む的に積極的に意識しようと思いました。

二つ目は、インフラや Vibe Coding に関する知識と経験です。

まず、インフラに関して、今回私たちは AWS のサービスをフルに活用してプロダクトを構成しました。私自身、AWS は S3, EC2, ALB, ECS, Route53 くらいしか知りませんでしたが、AWS の使用経験が豊富なチームメンバーがいたおかげで、各サービスやアーキテクチャの適切な構成について学びを深めることができました。特に、Bedrock, OpenSearch, Step Functions といった各種サービスや、awsume 等のツールを知れたことは非常に勉強になりました。

次に、Vibe Coding に関して、チームメンバーから学んだことをいくつかご紹介します。

• Vibe Coding の環境構築方法。MCP の接続設定を記述する（mcp.json）、AI 用ドキュメントの用意方法（claude.md, .claude/\*.md, agents.md）
• オススメの MCP。例えば、Context7, Senera, Cipher。

それぞれ、以下の記事が参考になりました。
https://zenn.dev/karaage0703/articles/3bd2957807f311
https://qiita.com/sukimaengineer/items/845ad14a3ec2d3c39930

（再掲）私たちのプロダクトのアーキテクチャ

感想

インターンに参加して感じたことや印象的だったエピソードも一部ご紹介します。

１点目に、PKSHA のインターンに参加することで、周囲の学生や自分の立ち位置、レベル感をなんとなく掴むことができました。このインターンはハッカソンのように非実務というわけでなく、かといって就業型のように常に社員さんやクライアントとやり取りをする、というわけでもありません。インターンでは実務のプロダクトに関するテーマが提供され、学生は他の学生とチームになって一気通貫で価値提供をするという点から、ハッカソンと就業型の中間に位置するのではないかと思います。だからこそ、インフラや上流の検証といったスキルも、自分の持ち味や新卒における相対的なポジションといった就活の所感も得ることができました。インターンでは就職活動の本選考の前段階としてこれらを知ることができるので、非常に貴重な機会だと考えています。

２点目に、小さな違和感でも放置しないようにしたいと思いました。これは、我々のチームに、開発を進める中で「Amazon Bedrock のリソースを大量に使ってしまった」というエピソードがあるためです。背景として、私たちの開発は Vibe Coding によって進めたと述べましたが、冒頭は Claude の Opus を利用していました。Claude のモデルには大きく Opus と Claude があり、Opus はコーディング文脈で高い性能を発揮する一方、そのコストは Claude の数倍にものぼります。また、Bedrock の利用トークン数や課金状況は Billing Dashboards から確認できるのですが、反映に 1 日程度かかります。そのため、Opus に実装面で大量にお世話になる中、その裏側で大幅にトークンが消費されていると気づくことができませんでした（原因 1）。加えて、チームメンバーの多くが、Claude Code は利用したことがある（Claude Code における利用状況の確認方法は知っていた）が、Amazon Bedrock 経由で Claude を利用するのが初めてで反映が遅い仕様に気づけなかったという理由もあります（原因 2）。

大きく膨らんだ Bedrock のコストグラフ

このエピソードを踏まえて、従量課金制のサービスでは特に、小規模に性能やコストの検証を進めるべきだったと痛感しました。他には、日々の夕会で利用方針や推定コストを報告する、既に同モデルを使っている人がいないか最新の記事を探す、などの対応も取ることができたと考えています。一方で、次の日にはこの事態に気づくことができ、Bedrock の利用モデル変更等の改善アクションが取れたため、さらなるコストの増加を抑えられたと思います。

このインターンが向いている人

いままでにご紹介した内容をもとに、どのような学生に本インターンがおすすめかを私なりに考えてみました。

• 今後ソフトウェア業界、特に AI SaaS 業界で活躍したいと思っている学生
• 要件定義から設計・実装、プレゼンまで一気通貫の流れを体験したい学生
• 企業の持つソリューションを活用するアイデア考案を通して、ドメインやプロダクトのキャッチアップ力を身につけ、企業の価値向上に貢献したい学生

おわりに

今回のインターンを通じて、プロダクト開発の初期フェーズにおける動き方やその難しさ、インフラや Vibe Coding に関する知識を学ぶことができました。PKSHA のこのインターンの後に参加した dely のインターンでも同様ですが、上流工程におけるデリバリーの質・速度を高めること、その方法を体得することを意識してインターンに参加していました。

同じインターンであっても、学生によって得る学びや体験の内容は、その学生のスキル特性やキャリアの方向性や段階などによってまったく違うと思います。たとえば、同じ PKSHA のインターンに別のチームとして参加していた齋藤くんも同様の参加体験記を執筆しているので、ぜひこちらも読んでいただければと思います。
https://qiita.com/saitojo1106/items/e573c2f7e7687850e139

サマーインターンを一通り終えて、自分が学ぶべきは、上流工程における質の高い言語化と、バックエンド・インフラの実装スキルだと分かってきました。これから、自分の目指すエンジニア像に向けて改めて具体的なプランを立て、動き出したいと思います。
ここまで読んでいただきありがとうございました。また、今回インターンを実施してくださった株式会社 PKSHA Technology のみなさま、本当にありがとうございました！

番外編（ごはん）

毎回恒例となってきましたが、最後に番外編として、社員の方やチームメンバーと一緒にいただいた、美味しかったごはんをご紹介します。

オードブル祭り 🎉

初日に懇親会として豪華な食事を用意していただきました。ローストビーフを食べるのが久しぶりで超美味しかったです。

三田製麺所（つけ麺）

オフィスから近くて何度かお世話になりました。友達が特盛食べてて腰抜かしました。

Bistro U（ビストロ）

オフィスから徒歩圏内にあるビストロです。コスパが超いい上に超うまいです。

夏祭り 🎉

特別に準備いただきました！夏も終わりに近づく中、このなつかしい雰囲気がインターン漬けになってしまった自分の心を癒してくれました 🫰

脚注

1. https://www.pkshatech.com/

2. https://aisaas.pkshatech.com/faq/

3. https://speakerdeck.com/pkshadeck/pksha-technology2027nian-xin-zu-samaintanshuo-ming-hui-zi-liao

4. https://x.com/PKSHA_saiyo/status/1962344661366067455