Capcom — Customer Story


Company name	Capcom Co., Ltd.
Industry	Games & Entertainment
Business	Planning, development, manufacturing, sales, and distribution of home video game software, mobile content, amusement equipment, and the like, as well as the operation of amusement facilities
Type of System	Front-end development, infrastructure construction and operation, CS development (CAPCOM ID system, etc.)

Interview Participants


Capcom	Akitoshi Yoshida, Team Leader, Web Infrastructure Team, Web Production Section, Production Department, Consumer Games Production Division Naofumi Nomura, Web Management Team, Web Production Office Ryota Mitsuhashi, Web Development Team, Web Production Office Ayato Shimada, Web Infrastructure Team, Web Production Office
Jitera	Takaaki Fujino, Customer Success Team

Challenges

Due to staff turnover and resignations, the development history of long-term projects had become a black box.

Engineers were using various AI tools individually, and the organization had no way to standardize or manage them.

Starting with infrastructure, know-how was lost each time the person in charge changed, making handover costs high.

Results

Visualizing specifications through reverse engineering greatly reduced the effort required to analyze black-boxed code.

AI analysis of IaC code and automatic documentation generation reduced infrastructure handover costs.

Things that “couldn’t be done before,” such as component-level documentation and test preparation, became achievable.

The role of engineers changed. The recipient of instructions shifted from “people” to “AI,” allowing engineers to focus on high-value-added work.

Looking Ahead

Aiming for a structure in which simple tasks are delegated to AI while humans focus on more advanced decision-making and design work.

Strengthening team-wide collaboration through real-time co-editing and context sharing.

Rolling out custom agents specialized for specific workflows to team members, expanding adoption across the entire organization.

Background to Adoption and Challenges

Please tell us how you first came to know about Jitera and the path that led to its adoption.

Mr. Yoshida: Right around this time last year, I was thinking about whether we could make code generation more efficient by linking source code with documentation. I had built a mechanism in-house and was testing it, but when I considered using it across the team, I felt the limits of having to keep maintaining it myself. When I searched for an off-the-shelf SaaS, I found Jitera and immediately thought, “This is exactly what I wanted to do,” so I reached out right away.

After that, following internal coordination on AI usage and securing the budget, we formally adopted it in November 2025. It took about six months from consideration to adoption, but I feel we were able to start in a way that the organization could genuinely buy into.

What kind of challenges did you face before adoption?

Mr. Yoshida: The biggest issue was the “black-boxing of development history” caused by staff turnover and departmental reorganization. Not only projects in the maintenance and operation phase, but ongoing projects as well, easily fell into a state where “no one knows what happened back then,” requiring us to grasp everything from scratch with every handover.

Mr. Mitsuhashi: By the time I began working on CAPCOM ID (an integrated membership service that can be used across Capcom’s various titles), the launch members had already been reassigned, and the structure of the related organizations had changed as well. As a result, I joined from a state in which accurate information about the project’s history and background had not been sufficiently organized. Since five years had passed since the start of operations, with revisions and feature additions made along the way, I thought reverse engineering using Jitera would be very effective.

Mr. Yoshida: Engineers were using various AI tools individually, but the usage environment was not unified across the organization, which made management cumbersome. Personally, I rated Claude highly for the accuracy of its code generation, but adopting it as an organization required internal coordination, which was a hurdle.

Reasons for Choosing Jitera

Among the many AI tools available, what were the key points that led you to choose Jitera?

Mr. Yoshida: The biggest deciding factor was the point that it “can hand context over to AI while linking source code and documentation.”

Simply by having it read existing repositories and documentation as context, you get answers grounded in on-the-ground knowledge. It was also significant that there was no need to build a mechanism ourselves and the team could start using it right away. Because development can proceed while documentation and code are kept constantly in sync, writing code and leaving a record for the next person in charge are naturally completed within the same task.

I felt we could take a realistic approach to “over-reliance on individuals,” which had been a long-standing challenge. When everyone uses different tools, knowledge does not accumulate at the organizational level. With Jitera, the fact that the team can share and accumulate context that includes both on-the-ground code and documentation was also a major deciding factor.

The ability to use multiple AI models such as Claude and ChatGPT on a single platform, choosing between them as the situation requires, also supports flexible use according to the purpose.

Current Usage

What kinds of system development work are you currently using Jitera for?

Mr. Nomura: We mainly use it for front-end development of esports-related sites and CAPCOM ID event and campaign pages. We feel it is especially effective for the work of turning components that designers create in Figma into code, and for implementing logic that can be completed with scripts.

Just by giving an instruction like “I want to attach this action to this button,” it handles everything from investigating which modules to use to generate the implementation code in one go. We had tried other tools before, but they didn’t deliver enough accuracy, so switching to Jitera turned out to be the right call.

What I particularly like is the cycle of first creating documentation for each component and then generating code based on it. By going back and forth, editing the documentation, reflecting it in the code, and then returning to the documentation, highly maintainable documentation is naturally developed at the same time as the implementation. As for ensuring code quality, we have established a workflow that uses AI to make test case verification more efficient.

Mr. Mitsuhashi: In the development of CAPCOM ID, we started by first having Jitera read the source code, reverse-engineering it, and grasping the specifications. From there we shifted our thinking and now use Jitera to “close the gap between our organization’s perceptions and reality.” We have it read, as context, the specifications and the history of bug responses accumulated in our internal information-sharing tools, and we compare these against the current state of things.

When you give information to Jitera, it reasons from a third-party perspective. To questions like “Is what we thought was a problem really an issue?” or “Are there other problems we’re not seeing?,” it returns answers from an objective viewpoint. I feel the greatest value is that things which were hard for us to notice on our own come into view.

We also put thought into how we use different LLMs. Depending on the purpose, such as code review or bouncing hypotheses around, we use Claude or ChatGPT accordingly. Furthermore, we perform a double-check by re-entering Jitera’s output into a separate chat to verify accuracy, which increases the reliability of the generated results.

Mr. Shimada: Infrastructure is, in most cases, basically built and operated by a single person, so the problem of “whether the next person will be in trouble when the person in charge changes” always follows us. Even when code written in IaC (Infrastructure as Code) is working, it is hard to leave behind the intent of why a given configuration was chosen. By analyzing and documenting IaC code with Jitera, the relationships between cloud resources and the intent behind the configuration are organized into a form that is easy for humans to read, which lets us create an environment that the next person can take over easily.

We also feel the benefits in building DevOps pipelines. It is often difficult to reuse previously built pipelines as is, but by analyzing and optimizing the code with Jitera, reuse across projects has become easier. In addition, by building a containerized execution environment, we have been able to make verifying the behavior of generated code more efficient as well. For things that require careful checking, such as cloud resources, we have also established a workflow of verifying them against the official documentation.

Effects After Adoption

After adoption, what kinds of changes occurred on the development floor?

Mr. Nomura: The biggest change is that “we can now do things we couldn’t do before.” Tasks like component-level documentation and test preparation, things we knew we ought to do but couldn’t, have become achievable. The time for each individual task has certainly decreased, but whenever time opens up we end up wanting to do the next thing, so the total volume of work has actually increased. It feels like the range of what we can do is expanding.

Mr. Mitsuhashi: When you use Jitera, you have to clearly put into words what it is you want to do. I feel that the accumulation of that practice is cultivating the team’s “ability to accurately verbalize challenges.” Right now we are at a stage where only some engineers are actively using it, but among the members who are, discussions have begun to arise about how much of our role humans should handle. I feel we are reexamining what we used to take for granted and taking a new step forward.

That change is also appearing in the role of engineers. A shift is emerging toward an “engineering leader’s way of working,” in which you organize tasks while taking a bird’s-eye view of the entire project and give instructions to AI. Spreading this throughout the whole organization is a challenge for the future, but it is certain that the members who have made use of AI have begun to create the trigger for change.

On Future Use of Jitera

Going forward, how would you like to use Jitera?

Mr. Nomura: As a basic direction, we are aiming for a model in which “simple work that humans don’t need to do is entrusted to AI, while humans focus on more advanced decision-making and design work.” By delegating to AI tasks such as investigating module specifications one by one and writing them up into documentation, we want to increase the time engineers can devote to their inherently creative work.

If there are any features or uses you are hoping for beyond that, please tell us.

Mr. Shimada: Right now, AI use is centered on individuals, but we would like to use features such as real-time collaborative document editing and context sharing to expand it to use across the whole team.

Mr. Mitsuhashi: At the moment I create and use a great many custom agents for my own use, but to be honest I’ve made too many of them (laughs). They have become very easy for me to use myself, but when I try to roll agents out to other members, I still can’t tell whether they are truly specialized for that particular workflow. Going forward, I would like to expand to the whole team by, for example, making it possible to configure agents through dialogue, and by using a mechanism that automatically lists up and loads the necessary context.

The challenge of “a break in the development history” caused by staff turnover and the disbanding of projects is one that many companies face, not only in the game industry.

Capcom’s initiative, having AI learn existing source code and documentation as context, and accumulating on-the-ground tacit knowledge as a team asset, will, I believe, serve as a valuable reference for the many companies that share similar challenges.

Thank you very much for taking the time to speak with us today.