Capabilities & Work

Areas

Technologies

Works

Work

Out of respect for confidentiality agreements, client names, product names, and specific details are withheld. This list includes projects our founder handled before establishing the company.

1. • Preprocessing time30 min → to3 min
   • Accuracy of the column-name prediction model85% → to96%

   Software development company (AI service for the construction industry)

   Improving an AI that predicts CO2 emissions from construction estimates, and building its inference API

   Our role

   Lead implementer across AI development (data processing, training, and inference API); later technical lead for all AI and data processing

   Areas

   Machine Learning & AI, DevOps & Automation

   • Python
   • Pandas
   • PyTorch
   • FastAPI
   • Amazon Bedrock
   • Amazon SageMaker
   • Amazon OpenSearch Service
   • Databricks
   • MLflow
   • Google Cloud Run
   • GitHub Actions

   Background

   This AI service predicts CO2 emissions from construction cost estimates (Excel). Because the estimate format differed for each tenant, preprocessing logic and models were built separately per tenant. Preprocessing was slow to run and costly to maintain. On top of that, there was no way to search construction procedure manuals, which contain figures and long tables, for the information needed.

   What we did

   • Rewrote preprocessing that relied heavily on loops to use vectorized operations in Pandas.
   • Built a retrieval-augmented generation (RAG) pipeline for manuals with figures and tables: Amazon Bedrock inserts summaries of figures into the text, and tables are split while preserving their structure before being indexed for search.
   • Consolidated scattered experiment environments on Databricks and used MLflow to record experiment parameters alongside model accuracy, so any model change can be checked for accuracy regressions.
   • Identified improvements to the model architecture and preprocessing of the AI that predicts column names in estimates.
   • Organized inference as a FastAPI API and handled model deployment to Google Cloud Run.

   Results

   Preprocessing time dropped from 30 minutes to 3 minutes. Accuracy of the column-name prediction AI improved from 85% to 96%. With experiment conditions and results now traceable, the groundwork is in place to move to analysis that no longer depends on per-tenant customization.

2. Software development company (music recommendation service)

   Porting an EEG analysis algorithm to Python and serving it as an API

   Our role

   Sole engineer from technology selection through porting, validation, and API development

   Areas

   Machine Learning & AI, Cloud Architecture

   • Python
   • NumPy
   • librosa
   • scikit-learn
   • PyTorch
   • FastAPI
   • Locust

   Background

   The project was to move an EEG analysis algorithm, written in MATLAB by an outside researcher, into a system usable by a music recommendation service. Because of license costs and runtime constraints, the original code had problems with inference speed and concurrent connections.

   What we did

   • Analyzed the signal processing, including fast Fourier transforms and mel spectrogram conversion, and reimplemented equivalent computations with NumPy and librosa.
   • Confirmed that the correlation coefficient between results before and after porting stayed at 0.8–0.9, verifying that the algorithm itself had not changed.
   • Built the API with FastAPI, ran load tests with Locust simulating more than 1,000 concurrent connections, and visualized resource usage over time.

   Results

   Working with limited hours, we completed technology selection, porting, testing, and API development on the 3-month schedule, contributing to the service’s commercial launch.

3. Software development company (entertainment)

   Building a conversational AI that reproduces a real person's way of speaking

   Our role

   Development lead (from design through deployment)

   Areas

   Machine Learning & AI

   • Python
   • LangChain
   • Streamlit
   • Azure AI Search
   • Azure OpenAI Service
   • Amazon Bedrock
   • LangSmith
   • MySQL
   • Docker
   • Kubernetes
   • GitHub Actions

   Background

   We developed a conversational AI that reproduces the tone and values of a real person. Answering factual questions correctly was not enough: the responses had to reflect the way the person speaks in their public posts and interviews. The challenge was to turn a vague requirement, “sounding like them,” into metrics that show which direction to improve in.

   What we did

   • Built a knowledge base from public posts and interview articles, and combined it with vector search on Azure AI Search.
   • Measured the similarity between generated output and the knowledge base with BLEU, and used LangSmith to trace each request from input to response. This lets us compare the effect of prompt changes with numbers, not just impressions.
   • Worked within the client’s existing Azure environment while choosing between Azure OpenAI Service and Amazon Bedrock by use case, balancing API cost against response speed.

   Results

   Through repeated prompt improvements and better retrieval accuracy, we reached a level of fidelity that earned high satisfaction from the person being reproduced. We handled everything from design through deployment.

4. Software development company (conversational AI service)

   Building an AI chat service that combines streaming responses with conversation history

   Our role

   Technical lead

   Areas

   Machine Learning & AI, Cloud Architecture

   • TypeScript
   • Next.js
   • Vercel AI SDK
   • LangChain.js
   • Zod
   • shadcn/ui
   • Vercel
   • Neon
   • Upstash
   • pnpm workspaces
   • GitHub Actions

   Background

   This was a conversational AI service meant to be both entertaining and useful. With AI SDK updates bringing one breaking change after another, we needed to add complex conversation history management without giving up fast streaming responses.

   What we did

   • Designed an architecture in which the Vercel AI SDK handles response streaming and LangChain.js handles prompt control and conversation history. We used a breaking change as the occasion to replace the parts that depended on the official template with our own implementation.
   • Migrated to a monorepo with pnpm workspaces and separated server-side processing from the UI. Cleaning up dependencies and strengthening type checking made frequent library updates easier to absorb.
   • Combined Neon (serverless PostgreSQL) and Upstash (Redis) on Vercel so each user’s data can be read and written with low latency.

   Results

   We established a process for keeping up with breaking changes in AI frameworks, and put in place a frontend architecture that can control complex conversation flows.

5. In-house

   Delivering a technical publication and designing a deployment path that publishes only verified builds

   Our role

   Design, implementation, and operations

   Areas

   DevOps & Automation, Cloud Architecture

   • Astro
   • TypeScript
   • Cloudflare Workers
   • OpenTofu
   • Google Cloud Build
   • Docker
   • GitLab

   Background

   This is our own publication for technical articles in Japanese and English. Our priorities were to keep operational effort and attack surface small as the number of articles grows, and to never publish a broken build.

   What we did

   • Kept articles, images, and sample code in separate repositories that are read only at build time, with Astro generating static HTML. The site is served through Cloudflare Workers static assets, with no runtime API or database.
   • Built checks into the build that stop publication when they detect broken links, outdated translations, partially failed builds, or unsafe HTML.
   • Defined the infrastructure as code with OpenTofu and manage it in a separate repository.
   • For deployment, we are moving to a setup where Google Cloud Build verifies a specific commit before producing the build artifacts, and only one process is allowed to update the hosting target. The build environment is never given the hosting API token.

   Results

   With no runtime server, there is little left to operate after publishing. We are continuing the migration of the deployment path so that it is always possible to confirm afterward who published which build.

6. Software development company (document management)

   Technical validation of a conversion engine for moving Office documents to lightweight formats

   Our role

   Technical lead (technology selection, prototyping, and technical report)

   Areas

   Machine Learning & AI

   • Rust
   • Tauri
   • Kotlin
   • docx4j
   • Google Cloud Functions

   Background

   To reduce dependence on a specific product, the client needed an engine that converts Microsoft Office documents (.docx, .pptx) into lightweight formats such as Markdown. Existing Java-based libraries struggled to accurately reproduce equations (OMML) and layout information.

   What we did

   • Evaluated the existing JVM-based approach with Kotlin and docx4j, then chose Rust for the parsing work, which demands performance and memory safety.
   • Analyzed the internal data structures of Office documents based on their XML Schema and identified the elements existing libraries cannot reproduce. For difficult areas such as equation conversion, we set a plan to implement them ourselves in Rust.
   • Built the prototype as a desktop app with Tauri and confirmed that it runs on multiple operating systems.

   Results

   The prototype surfaced the key technical hurdles and implementation costs, and we produced a technical report and implementation roadmap for the next-generation system.

7. Large enterprise (internal IT)

   Automating security patch distribution and management for about 3,000 endpoints

   Our role

   Technical lead (responsible for technical decisions on a three-person team)

   Areas

   DevOps & Automation, Cloud Architecture

   • Active Directory
   • Group Policy
   • WQL
   • VBA

   Background

   The project was to apply security patches to about 3,000 Windows endpoints and migrate them to a new endpoint security product. The Active Directory at the center of it had no administrator, and there was neither anyone who could explain its configuration nor any documentation.

   What we did

   • Analyzed the existing Active Directory configuration and Group Policy one setting at a time from the servers themselves, and redesigned a path for safe distribution.
   • Wrote WQL conditions to target the right endpoints precisely, and used VBA to automate the Excel workbook that tracks the distribution plan and progress. We also standardized the procedures for organizational unit (OU) changes and rollbacks.
   • Proposed a team structure that separates technical work from internal approvals and coordination.

   Results

   We eliminated errors from manual tallying and reduced management work by about 60 hours a month, while maintaining a 100% patch application rate.

8. Training program hosted by a regional IT industry association

   Teaching engineer training and developing generative AI and Go course materials

   Our role

   Instructor and course material developer

   Areas

   Machine Learning & AI

   • Go
   • Python
   • LangChain
   • Streamlit
   • PyTorch
   • TensorFlow

   Background

   We taught Go and generative AI in an engineer training program run by an association that promotes the regional IT industry. The existing materials lacked coverage and accuracy, and needed to be reworked to a level engineers could apply on the job.

   What we did

   • Reviewed the Go materials in detail and rebuilt them from start to finish around an accurate understanding of the language specification and practical topics such as concurrency.
   • Developed a new hands-on course using LangChain and Streamlit to build a retrieval-augmented generation (RAG) system in 4 hours.
   • Produced explainer videos and materials on object detection with PyTorch and TensorFlow.

   Results

   We taught more than 50 engineers and received a rating of 4.5 out of 5 in the participant survey.

Credentials

Certifications

Our team holds the following certifications.

Cloud

• Google Cloud Professional Cloud Architect
• Google Cloud Professional Cloud DevOps Engineer
• Google Cloud Professional Cloud Security Engineer

Security

• Passed the Registered Information Security Specialist Examination (IPA, Japan)

Machine learning

• JDLA Deep Learning for ENGINEER (E-Certification)